测试下你部署的反向加速代理是否能正确处理反应速度很慢的 backend 吧

[sNullp]

写了个故意以很慢速度返回 HTTP 内容的脚本。部署下面这个脚本到 localhost，然后给反代增加一个 domain （比如 test.test） 指向 localhost:6789。



然后你就可以用 curl -vv -H "<<Your headers>>" 来测试你的加速反代了。

注意：下面的例子中的正确行为是我猜测的，并不一定符合标准。每个例子中两个 curl 是在一起执行的（不是一个跑完了跑第二个）。

例子1:
第一个 curl：
curl -vv test.test
正确行为：脚本得到 GET 请求，开始慢慢返回。同时 curl 能立刻按行返回，不需要等到整个文件传输完成。
第二个 curl：
（等待几秒）curl -vv test.test
正确行为：脚本并不会显示 Accept 到了新连接。前一个请求已经得到的数据应当立刻返回，之后两个 curl 同步按行返回新数据。

例子2:
第一个 curl：
curl -vv test.test
正确行为：脚本得到 GET 请求，开始慢慢返回。同时 curl 能立刻按行返回，不需要等到整个文件传输完成。
第二个 curl：
（等待几秒）curl -vv -H "Ranges: bytes=a-b" test.test
正确行为：脚本并不会显示 Accept 到了新连接。应当正确返回 206 并且包含正确数据（可看 Content-Range 头）。如果 a 小于已传送的数据则已传送的数据应该立刻显示，否则将等待直到相应数据传输过来再显示。之后两个 curl 数据同步直到遇到 b。

例子3:
第一个 curl：
curl -vv -H "Ranges: bytes=a-b" test.test
正确行为：脚本得到 GET 请求，并且请求不应当包含 Ranges（反代应当请求整个文件）。同时 curl 会等待直到有效数据返回，不需要等到整个文件传输完成。
第二个 curl：
（等待几秒）curl -vv -H "Ranges: bytes=a-b" test.test
正确行为：脚本并不会显示 Accept 到了新连接。应当正确返回 206 并且包含正确数据（可看 Content-Range 头）。如果 a 小于已传送的数据则已传送的数据应该立刻显示，否则将等待直到相应数据传输过来再显示。之后两个 curl 数据同步直到遇到 b。

[sNullp]

真是醉了。。这种纯技术贴居然连踩的都没有。。