Re: NEW ISSUE: message-body in CONNECT response

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" 
argument?

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.




Robert

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