http 1.1 管道客户端实现
支持管道的 http 1.1 客户端实现的编程模型是什么？我对管道 POST 感兴趣。
What would be the programming model for an http 1.1 client implementation with support for pipeling? I am interested in pipeling POSTs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你的问题对我来说似乎又回到了前面。如果您对管道感兴趣，您心中一定已经有了一个编程模型。 RFC 确实规定 POST 不应该被管道化。
You question seems to be back to front to me. If you're interested in pipelining you must already have a programming model in mind. And the RFC does say that POST shouldn't be pipelined.
正如 EJP 已经提到的，POST 不应该被管道化。但由于“应该”不是“必须”，我将向 hotpotato 很快。
不确定您是在寻找现有的实现还是想要创建自己的实现......无论哪种方式，该项目都会派上用场:)
As EJP already mentioned, POSTs shouldn't be pipelined. But since "SHOULD" is not "MUST", I'll be adding pipelining support (yes, POSTs will also be supported) to hotpotato pretty soon.
Not sure whether you're looking for an existing implementation or wanting to make one of your own... Either way, that project could come in handy :)
开发人员还在努力为 异步 HTTP 客户端 添加 HTTP 管道支持在 github 上。
关于管道 POST，人们可能希望将“不应该”读作与“不要”几乎相同的内容——如果标准说明符认为这是一个坏主意，也许是这样？ ——但也许在某些特定的用例中，众所周知，POSTS（缺乏幂等性）的一般未知数是不正确的，因此这是有道理的。
There is also work under way by a developer to add HTTP pipelining support for Async HTTP Client at github.
With respect to pipelining POSTs, one might want to read "should not" pretty much same as "DO NOT" -- if standard specifier thinks it's a bad idea, maybe it is? -- but perhaps there are specific use cases where it is well known that general unknowns with POSTS (lack of idempotency) are not true, and thereby it makes sense.
我认为jboss的netty支持管道。
请查看此处了解更多详细信息。
I think jboss's netty supports pipelining.
Have a look here for more details.