【发布时间】：2015-01-18 08:02:37
【问题描述】：
有谁知道如何检测对 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 标头，即使它们没有实际上关闭连接，因为这是他们可以做的最接近方法#5的事情。有些代理甚至不提供任何标题，只是一个状态行，后跟一个 CR/LF。
您是否应该使用一种特殊的方式来处理在另一个 RFC 中定义的这些响应，或者在我设法忽略的部分中？定义 CONNECT 方法的 RFC 的第 9.9 节严重缺乏指定如何处理该方法，因为它只有一个句子。
【问题讨论】：
标签： http proxy response connect