我正试图编写一个程序来匹配HTTP请求与其相应的响应。似乎在大多数情况下，一切都工作得很好(当传输是完全有序的，甚至当它不是，通过使用TCP序列号)。
我发现的唯一问题是当我有流水线请求时。在那之后，我得到了几个响应，但我不知道哪些数据包是对特定请求的回答，哪些不是。我在另一篇文章中读到，响应将按顺序出现，并将此属性与Content-Length字段的信息相结合似乎是一种解决方案。问题是Content-length不是一个必填字段，所以我不确定我是否总是可以依赖它。
有谁知道支持这个功能的浏览器(顺便说一句，不是大多数)是怎么做的吗?
关于正文长度的信息必须出现在标题中。它只是不总是"内容长度"。为了解决这一切，你必须研究相关的RFC 2616。最值得注意的是，第4.4节处理了不同的头文件
RFC 2616中的一些相关规则:
当流水线:
服务器必须按照接收请求的顺序发送响应。
如果不包含响应体，则响应必须包含一个字段值为"0"的Content-Length字段。
From 10.2.7 206部分内容
响应必须包含....Content-Range报头字段…或者多部分/字节内容类型，包括每个部件的内容范围字段。
From 14.13 Content-Length
应用程序应该使用这个字段来指示消息体的传输长度，除非4.4节中的规则禁止这样做。
当前的响应有点陈旧。需要刷新一下
新的HTTP 1.1 RFC是RFC 7230。并包含解析消息大小的更精确信息。
- 消息体长度
- 关联请求响应
- 安全考虑
检测消息的大小是相当复杂的。你可以有Content-length，或者Transfer-Encoding: chunked，或者两者都有，或者没有。和一些特殊的代码，如100 Continue，可能会改变这一切。
第一个链接包含7个条目，应该按正确的顺序检查以猜测正确的大小。
正如上一个链接所述，未能检测到正确的消息长度可能会导致HTTP走私(分裂，缓存中毒)问题。
流水线支持是大多数走私问题的根源。如果你想实现RFC7230，你应该认真对待整个RFC7230文档