Re: CONNECT command with message body

Jamie Lokier wrote:
> The spec reads to me like a client can send CONNECT followed by data
> to be tunnelled immediately if the CONNECT is successful.
>
>   
That's how I read it too, but it's difficult to know whether the 
implication is about tunneling raw data that follows the HTTP message 
that sets up the connection, vs the message which sets up the connection 
containing an entity-body.

If you have an entity-body on the CONNECT message, you could interpret 
this 2 ways.

1. ignore it:

a) The entity-body is part of the message
b) the purpose of the message is to establish a connection
c) therefore the entity-body is part of the establishment of the 
connection, not data to be relayed

2. forward it.

the language used seems to refer more to tunneled data being sent along 
with the message.  But including a Content-Length header makes the data 
an entity-body in this bluray player's case.

It's interesting, I've also been looking over a relatively recent 
discussion on this list about entity-body on responses to CONNECT.

There are so many bits of HTTP that really make no sense at all for the 
CONNECT method.  Such as chunking, transfer-encoding, content-encoding, 
entity headers etc.  It really bears little resemblance to HTTP at all.  
In fact once the connection is established, it is no longer necessarily 
HTTP.

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.

So all in all, beefing up 2817 could be useful, or some sort of 
clarification somewhere.  I'm presuming CONNECT is out of scope for HTTPbis.

Adrien

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

Received on Tuesday, 5 May 2009 12:26:19 UTC