Re: NEW ISSUE: message-body in CONNECT response

I agree with Roy about maintaining correctness of message semantics.  We 
can't have the CONNECT method being the only one where the response 
doesn't need to be a well-formed, _complete_ HTTP message.

However, we do use in some cases a message body on a 2xx response to a 
CONNECT to present a Java based login page.  Some clients handle this 
better than others.  We've been doing this for years and had few issues 
with it. I'd actually love to deprecate this behaviour, but our 
customers want it.

The current spec in my view allows a body, we're talking about removing 
that functionality. 


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.
>
> ....Roy
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 27 November 2007 21:10:03 UTC