Re: CONNECT command with message body

For me S 5.2 is a bit vague.  It talks about "Other HTTP mechanisms can 
be used normally"... whatever they may be.  Would this other mechanisms 
include sending a message body?

The pipelining clause is very odd as well.  If tunnelling is used for 
any protocol other than HTTP (e.g. SSL/TLS which is an extremely common 
use-case) then pipelining doesn't make any sense. 

It talks about "data to be tunneled may be sent immediately after the 
blank line".

"the blank line" could be considered to be the separator between request 
headers and request body, and therefore anything in the request after 
the headers should be forwarded through to the target after the 
connection is made, or discarded if the connection fails.

It would be great if it explicitly mentioned whether a body is legal or 
not.  IMHO it makes no sense to have a body on CONNECT, all it does is 
save a small amount of time (the amount of time it takes the proxy to 
signal successful connection and the client to then send the subsequent 
data to the proxy).  Client <-> Proxy comms is usually at local LAN 
speeds for CONNECT.

Another point is that the CONNECT command has been around much longer 
than RFC2817.  Even longer than RFC2616, in which the method name was 
reserved.  It's a highly important and heavily used method, probably 2nd 
after GET for most web browsers configured to use a proxy.  Maybe even 
more used than GET if you count the spammers.  It therefore deserves a 
decent spec which covers the basics like message bodies.

I'm coming to the conclusion that message bodies on CONNECT are de-facto 
illegal though which helps my client with the blu-ray player.

Thanks

Adrien

Daniel Stenberg wrote:
> On Tue, 5 May 2009, Adrien de Croy wrote:
>
>> Is it even legal for a CONNECT command to have a body?  If it does, 
>> what should the proxy do?  The client (a panasonic blue-ray player) 
>> breaks if the body is forwarded, however RFC2817 Sec 5.2 last para 
>> implies it is legal to have a body here.
>
> Sorry, but can you clarify how you would read that paragraph to get 
> that meaning out of it? (I'm not suggesting you think this, I just 
> don't see how it can be intrepreted that way.)
>
> Here's that last paragraph of RFC2817 5.2 with my comments:
>
>    Like any other pipelined HTTP/1.1 request, data to be tunneled may be
>    sent immediately after the blank line.
>
> This seems to be like it's saying that everything after the blank line 
> is tunneled. And it also mentions pipelining (in a funny way if you 
> ask me), which only works for requests with no request-bodies.
>
>    The usual caveats also apply: data may be discarded if the eventual
>    response is negative, and the connection may be reset with no 
> response if
>    more than one TCP segment is outstanding.
>
> Is it that "data may be discarded" part? It's not clear to me what 
> data this refers to.
>

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

Received on Tuesday, 5 May 2009 09:47:14 UTC