Question

有谁知道如何检测对CONNECT请求的响应结束？我一直在编写自己的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（可能还有其他）代理发送一个Connection：close header尽管他们实际上并没有关闭连接，因为这是他们可以做的最接近的方法来支持方法＃5。有些代理甚至不提供任何标题，只有状态行后跟CR / LF。

您是否应该采用一种特殊的方式来处理这些在另一个RFC或我设法忽略的部分中定义的响应？定义CONNECT方法的RFC的第9.9节严格缺乏指定如何处理此方法，因为它只是一个句子。

Answer 1

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

http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-26.html#CONNECT

Answer 2

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

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

2 个答案: