- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 18 Oct 2010 15:22:20 +1100
- To: Dan Winship <dan.winship@gmail.com>
- Cc: ietf-http-wg@w3.org
Now that we've taken on CONNECT from RFC2817, this is: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/250 Cheers, On 27/11/2007, at 6:21 AM, Dan Winship wrote: > > As implemented in the real world, a successful response to a CONNECT request does not include a message-body. But this isn't stated in RFC 2817, and is actually forbidden by RFC 2616. > > draft-luotonen-web-proxy-tunneling said: > > Example of a response: > > HTTP/1.0 200 Connection established > Proxy-agent: Netscape-Proxy/1.1 > > ...data tunnelled from the server... > > After the empty line [that follows the message-headers], the proxy > will start passing data from the client connection to the remote > server connection > > but RFC 2817 (5.3) removes the lack-of-message-body implication: > > Any successful (2xx) response to a CONNECT request indicates that > the proxy has established a connection to the requested host and > port, and has switched to tunneling the current connection to that > server connection. > > And RFC 2616 (4.3) requires a 200 response to a CONNECT to have a message-body anyway: > > All responses to the HEAD request method MUST NOT include a > message-body, even though the presence of entity-header fields might > lead one to believe they do. All 1xx (informational), 204 (no > content), and 304 (not modified) responses MUST NOT include a > message-body. All other responses do include a message-body, > although it MAY be of zero length. > > > So to fix things, RFC 2616 4.3 should be updated to include "A successful (2xx) response to a CONNECT request MUST NOT include a message-body." And if 2817 is in-scope for 2616bis then the fact should probably be reiterated there too. > > -- Dan > -- Mark Nottingham http://www.mnot.net/
Received on Monday, 18 October 2010 04:22:51 UTC