HTTP 1.1-连接方法-如何确定响应结束？

有人知道如何检测连接请求响应的结束吗？我一直在编写自己的HTTP堆栈，并注意到大多数代理似乎以不同的方式响应此请求，其中没有一个符合RFC。具体而言，RFC 2616第4.4节：

   1.Any response message which "MUST NOT" include a message-body (such
     as the 1xx, 204, and 304 responses and any response to a HEAD
     request) is always terminated by the first empty line after the
     header fields, regardless of the entity-header fields present in
     the message.

   2.If a Transfer-Encoding header field (section 14.41) is present and
     has any value other than "identity", then the transfer-length is
     defined by use of the "chunked" transfer-coding (section 3.6),
     unless the message is terminated by closing the connection.

   3.If a Content-Length header field (section 14.13) is present, its
     decimal value in OCTETs represents both the entity-length and the
     transfer-length. The Content-Length header field MUST NOT be sent
     if these two lengths are different (i.e., if a Transfer-Encoding
     header field is present). If a message is received with both a
     Transfer-Encoding header field and a Content-Length header field,
     the latter MUST be ignored.

   4.If the message uses the media type "multipart/byteranges", and the
     ransfer-length is not otherwise specified, then this self-
     elimiting media type defines the transfer-length. This media type
     UST NOT be used unless the sender knows that the recipient can arse
     it; the presence in a request of a Range header with ultiple byte-
     range specifiers from a 1.1 client implies that the lient can parse
     multipart/byteranges responses.

       A range header might be forwarded by a 1.0 proxy that does not
       understand multipart/byteranges; in this case the server MUST
       delimit the message using methods defined in items 1,3 or 5 of
       this section.

   5.By the server closing the connection. (Closing the connection
     cannot be used to indicate the end of a request body, since that
     would leave no possibility for the server to send back a response.)

假设代理支持CONNECT方法，并且没有将我尝试连接的主机/端口列入黑名单，则它们返回状态代码200，理论上可能包含消息正文，因此我无法使用方法1。我测试过的代理中没有一个包含允许我使用方法2-4的头文件。由于CONNECT方法提供类似于SOCKS代理的行为，因此连接必须保持打开状态，因此我不能使用方法5。我见过的最接近的方法是Fiddler（可能还有其他）代理发送连接：close header，即使它们实际上没有关闭连接，因为这是它们可以做的最接近于支持方法5的事情。有些代理甚至不提供任何标题，只是一个状态行，后跟一个CR/LF

---

你有没有一种特殊的方式来处理这些在另一个RFC中定义的响应，或者在我设法忽略的部分中定义的响应？RFC第9.9节定义了连接方法，但由于该方法只是一句话，因此严重缺乏对该方法处理方式的详细说明。

因此，在新提议的RFC中，它们确实定义了如何处理连接响应。它们不能包含消息体，并且您通过一个空行（CR/LF）确定响应的结尾

---

没有真实的身体。所有连接请求和响应都是建立一个以连接关闭结束的隧道。有关规格，请参阅