Re: CONNECT command with message body

p.s.  more information on this.

As part of the general theory that CONNECT or its response message may 
contain an entity-body, I did some testing with including a 
Content-Length header in the response message.

This caused a lot of problems for some browsers.

1. Goole chrome crashed immediately.
2. Firefox reported that it was still waiting for transfers to complete 
even though everything had been sent through. 
3. IE 7, ok.

in the case of Chrome and Firefox, the problems went away as soon as the 
Content-Length header was removed from the connect response.

I view this as a bug in FF and Chrome, however it's odd that these 
browser at least consider that it's illegal to have an entity body on a 
CONNECT reponse, and it makes me therefore highly reluctant to put the 
header in.

Adrien




Adrien de Croy wrote:
>
> Did we get anywhere with this issue?
>
> I just made some mods to the proxy to ignore any entity body on 
> CONNECT (e.g. not forward it to the server).  This then leads to 
> issues around understanding when the request message is complete.
>
> Fundamentally, if a message may have an entity, then the message is no 
> longer delineated by the empty line that terminates the headers.
>
> If no Content-Length field is present, and no Transfer-Encoding 
> specified, then presumably for any request there will be no entity, 
> since the client would need to disconnect to signal the end of the 
> entity body.
>
> Is this a fair assumption to make?
>
> Adrien
>
>
> Daniel Stenberg wrote:
>> On Wed, 6 May 2009, Adrien de Croy wrote:
>>
>>> I think some of the wording of RFC2817 was contemplating HTTP being 
>>> used over the connection, which would explain some of the comments.  
>>> However I don't know of any cases of this (raw HTTP over CONNECT, 
>>> rather than over TLS over CONNECT), and it's pretty much pointless 
>>> since the normal proxy semantics would achieve the same thing.  You 
>>> therefore use CONNECT when you want to use some protocol other than 
>>> HTTP (e.g. SSL/TLS) over the connection.
>>
>> Pointless if the behavior is identical to everyone, yes.
>>
>> I can think of many situations where you'd either just (A) CONNECT 
>> and send plain HTTP GET through, or the more complicated setup: (B) 
>> CONNECT, tunnel ssh over to a remote proxy, and then send HTTP GET 
>> over that tunnel, to avoid local proxy 
>> enforcements/filters/logs/prying eyes.
>>
>> Of course I'm just blindly guessing here that proxies will treat the 
>> case (A) differently than a normal GET in such aspects. I know case 
>> (B) is widely used though.
>>
>

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

Received on Monday, 18 May 2009 04:12:58 UTC