RE: NEW ISSUE: message-body in CONNECT response

Wouldn't "Connection: Close" be more appropriate than "Content-Length: 0", as the latter implies that no content follows, while clearly that's not correct if the response headers precede blobs of HTTPS traffic?

A proxy that supports HTTPS tunneling is going to use Connection: close semantics anyway, right?

Vis--vis the idea of responding to a CONNECT request with a HTML 2xx "login" page, it may be worth mentioning that this does not work in IE6 or IE7. A user-agent which does support such responses must be very careful to ensure that the security context of the returned content is corrected to reflect its insecure nature.

Eric Lawrence
Program Manager - IE

-----Original Message-----
From: [] On Behalf Of Roy T. Fielding
Sent: Tuesday, November 27, 2007 11:03 AM
To: Jamie Lokier
Cc: Bjoern Hoehrmann; Dan Winship;
Subject: Re: NEW ISSUE: message-body in CONNECT response

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


Received on Tuesday, 27 November 2007 21:37:26 UTC