W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: NEW ISSUE: message-body in CONNECT response

From: Robert Siemer <Robert.Siemer@backsla.sh>
Date: Wed, 28 Nov 2007 02:57:01 +0000
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Jamie Lokier <jamie@shareable.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Dan Winship <dan.winship@gmail.com>, ietf-http-wg@w3.org
Message-ID: <20071128025729.GB1872@polar.elf12.net>

On Tue, Nov 27, 2007 at 11:03:04AM -0800, Roy T. Fielding wrote:
> On Nov 27, 2007, at 4:32 AM, Jamie Lokier wrote:
> >Bjoern Hoehrmann wrote:
> >>Do you have any information on how clients treat the response if  
> >>it has
> >>a Transfer-Encoding or Content-Length header? What if the response is
> >>not a 2xx one and includes (or lacks) these headers?
> >
> >I can say for sure that some clients* using CONNECT just check the
> >response code, and if it's 2xx they read until the first blank line,
> >then assume what follows is the tunnelled data.  Such implementations
> >don't parse the headers at all.
> >
> >* - Not HTTP clients as such, but clients of other protocols which
> >    have an option to connect through a HTTP proxy using CONNECT.
> The standard requires an empty body on a non-closed connection to be
> indicated by one of the two message length indications (CL or TE  
> chunked).
> In this case, the obvious solution is to require "Content-Length: 0" be
> included in the header fields of the 200 response.  It doesn't matter
> if some clients ignore that field.  What matters is that we don't add
> more method-specific parsing of response bodies.

I can tell you, the RFC2616 is definitively not written to make 
implementators life easy, so why draw the "method-specific parsing" 

As of RFC2616 a 200 does not mean the response is going to have a 
body, so why enforce that for CONNECT? The proxy has to be aware of that 
method anyway for it to work.

Received on Wednesday, 28 November 2007 10:02:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC