Re: CONNECT message including tunneled data

tis 2008-01-29 klockan 18:16 +0100 skrev Robert Siemer:

> Some time ago we had the discussion about the CONNECT responses and that 
> they should carry a Content-Length header if the result code is 200.

It's unspecified if a response entity on the 2xx response to CONNECT is
part of the CONNECT status response, or part of the tunnelled data.

CONNECT is special from all other HTTP methods in that a successful
CONNECT request establishes a bidirectional transport tunnel over the
proxy. Unfortunately specifications in RFC2817 do not define the meaning
of any request/response entity used in the message exchange for
establishing the tunnel, but it's pretty clear that use of the protocol
format had not been considered.

But it do say that data may be immediately pipelined after the "blank
line".

Note: If CONNECT had been specified for HTTP/1.1 and not 1.0 it would
probably look a little different, for one thing quite likely using an
1xx response code like Upgrade and not 2xx.


In field experience I have seen the following three forms used:

a) The normal plain one with no request/response entities. Just
request/response headers immediately followed by tunnelled data.

b) Content-Length: 0 in either request or response. I think there was
some JRE version doing this for example but not entirely sure..

c) A few random applications using CONNECT as if it was a normal HTTP
method, with both request and response entities, and everyone involved
seeing that (including app vendors) seeing it as a bug.



What we do in Squid (after some user pressure) is to ignore any
Content-Length seen on CONNECT requests or 2xx responses to CONNECT. In
the past we rejected CONNECT requests with Content-Length and got a very
small number of questions about this..

Regards
Henrik