我正在尝试编写一个程序来匹配 HTTP 请求及其相应的响应。似乎在大多数情况下一切都运行良好（当传输完全有序时，即使它不是，通过使用 TCP 序列号）。
我发现的唯一问题是当我有流水线请求时。之后，我收到了几个响应，但我不知道哪些数据包是特定请求的答案，哪些不是。我在另一篇文章中读到，响应将按顺序出现，将此属性与 Content-Length 字段上的信息结合起来似乎是一种解决方案。问题是 Content-length 不是必填字段，所以我不确定我是否总是可以依赖它。
有谁知道支持此功能的网络浏览器（顺便说一句，不是大多数人都这样做）实际上是如何做到的？
有关正文长度的信息必须存在于标头中。它并不总是在“内容长度”中。为了解决所有问题，您必须研究相关的 RFC 2616。最值得注意的是第 4.4 节处理不同的标头
来自RFC 2616的一些更相关的规则：
流水线时：
服务器必须以与接收请求相同的顺序发送对这些请求的响应。
从 9.2 开始
，如果没有包含响应正文，则响应必须包含一个 Content-Length 字段，其字段值为“0”。
从 10.2.7 开始 206 Partial Content
响应必须包括 .... Content-Range 头字段 ... 或 multipart/byteranges Content-Type，包括每个部分的 Content-Range 字段。
从 14.13 Content-Length
应用程序应该使用该字段来指示消息体的传输长度，除非这被第 4.4 节中的规则禁止。
当前的响应有点陈旧。需要刷新。
新的 HTTP 1.1 RFC 是RFC 7230。并包含有关解析消息大小的更精确信息。
检测消息的大小非常复杂。你可以有一个Content-length，或Transfer-Encoding: chunked，或两者，或没有。还有一些特殊的代码100 Continue可能会改变这一切。
第一个链接包含 7 个条目，应按正确的顺序检查以猜测正确的大小。
如上一个链接所述，未能检测到正确的消息长度可能会导致 HTTP Smuggling（拆分、缓存中毒）问题。
流水线支持是大多数走私问题的根源。如果你想实现它，你真的应该照顾整个 RFC7230 文档。