将 HTTP 响应与其相应的 HTTP 管道请求相匹配
我正在尝试编写一个程序来将 HTTP 请求与其相应的响应相匹配。似乎在大多数情况下一切都运行良好（当传输完全有序时，甚至当传输不有序时，通过使用 TCP 序列号）。
我发现的唯一问题是当我有管道请求时。之后，我收到了几个响应，但我不知道哪些数据包是特定请求的答案，哪些不是。我在另一篇文章中读到，响应将按顺序出现，并将此属性与 Content-Length 字段上的信息结合起来似乎是一个解决方案。问题是 Content-length 不是必填字段，所以我不确定我是否可以始终依赖它。
有谁知道支持此功能的网络浏览器（顺便说一句，不是大多数）实际上是如何做到的？
I'm trying to write a program to match HTTP requests with their corresponding responses. Seems that everything is working well for most of the scenarios (when the transfer is perfectly ordered and even when its not, by using TCP sequence numbers).
The only problem I found is for when I have pipelined requests. After that, I get several responses but I don't know which packets are the answer to a specific request and which are not. I read in another post that the responses will come sequentially and combining this property with information on the Content-Length field seems to be a solution. The problem is that Content-length is not a mandatory field, so I'm not sure if I can always rely on that.
Does anyone know how the web-browsers that support this feature (btw, not most of them do) actually do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有关主体长度的信息必须出现在标头中。它并不总是在“内容长度”中。为了解决所有问题，您必须研究相关的 RFC 2616。最值得注意的是第 4.4 节处理不同的标头
RFC 2616：
管道传输时：
服务器必须按照接收请求的顺序发送对这些请求的响应。
从 9.2 开始
如果不包含响应主体，则响应必须包含字段值为“0”的内容长度字段。
自 10.2.7 起 206 部分内容
响应必须包含 .... Content-Range 标头字段 ... 或 multipart/byteranges
Content-Type 包括每个部分的 Content-Range 字段。
从 14.13 内容长度开始
应用程序应该使用此字段来指示消息主体的传输长度，除非第 4.4 节中的规则禁止这样做。
The information about the bodies length has to be present in the headers. It's just not always in 'content-length'. In order to work it all out you will have to study the relevant RFC 2616. Most notably section 4.4 deals with the different headers
Some more relevant rules from the RFC 2616:
When pipelining:
A server MUST send its responses to those requests in the same order that the requests were received.
From 9.2
If no response body is included, the response MUST include a Content-Length field with a field-value of "0".
From 10.2.7 206 Partial Content
The response MUST include .... Either a Content-Range header field ... or a multipart/byteranges
Content-Type including Content-Range fields for each part.
From 14.13 Content-Length
Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.
当前的回复有点旧。需要刷新一下。
新的 HTTP 1.1 RFC 是 RFC 7230。并包含有关解析消息大小的更精确信息。
检测消息的大小相当复杂。您可以有
Content-length或Transfer-Encoding: chunked，或两者都有，或没有。一些特殊代码，例如100 Continue可能会改变这一切。第一个链接包含 7 个条目，应按正确的顺序检查这些条目以猜测正确的大小。
正如最后一个链接所述，未能检测到正确的消息长度可能会导致 HTTP 走私（分裂、缓存中毒）问题。
管道支持是大多数走私问题的根源。如果你想实现它，你真的应该仔细阅读整个 RFC7230 文档。
Current responses are a bit old. Need a refresh.
The new HTTP 1.1 RFC is RFC 7230. And contains more precise information on parsing the messages size.
Detecting the size of a message is quite complex. You can have a
Content-length, orTransfer-Encoding: chunked, or both, or none. And some sepcial codes like100 Continuewhich may alter all this.The first link contains 7 entries that should be checked in the right order to guess the right size.
And as stated in the last link, failing to detect the right message length may lead to HTTP Smuggling (splitting, cache poisoning) issues.
Pipelining support is the source of most smuggling issues. You should really take care of the whole RFC7230 document if you want to implement it.