Re: CONNECT message including tunneled data

Jamie Lokier wrote:
> Adrien de Croy wrote:
>   
>>>> What other HTTP method allows you to send any amount of data back
>>>> and forth not delineated into HTTP messages?
>>>>         
>>> POST :-)
>>>       
>> back and forth and back and forth and back and forth etc etc with a
>> single command and response?
>>     
>
> Yes, when supported by intermediaries (i.e. often no).
>
>   
Right - because everything needs for starters to be HTTP/1.1 compliant, 
else you can't send chunked requests

>>> However, since overlapping request/response doesn't work with many
>>> agents, it is more common to issue two POSTS (or 1 POST, 1 GET) on
>>> separate connections, one for the upstream data, and one for the
>>> downstream data.  People do actually use this method already.
>>>
>>>       
>> I would have thought it would be easier to use CONNECT :)
>>     
>
> It's not possible to use CONNECT, if you want to establish a two way
> message stream with some remote server.  The intermediaries will
> intercept CONNECT, but they will forward POST (or POST+GET pair).
> They get converted into application streams at the server, dependent
> on particular URLs.
>
>   
lost me there - you mean then establishing a 2-way stream with some 
remote HTTP process?

>> Whilst I'd love to see HTTP move to a more state-driven
>> multi-transactional multiplexed command protocol,
>>     
>
> A nice turn of phrase.  While we're at it, let's add lease-based
> tree-structured caching, delta transmission, and peer to peer
> distributed hashing :-) No, just half-joking...
>
>   
don't hold back! :)

>> it would
>> no longer be or bear any resemblance to HTTP.  You'd need to assign a
>> new port number for it :)
>>     
>
> As long as the new port number is 80, for deployment reasons :-)
>
>   
can you imagine trying to support both protocols over the same port?

>>> Only when the proxy is near the client.  
>>>       
>> Sure - that's what I meant by normally.
>>     
>
> I'm not sure if that's the normal use of
> two-way-streaming-over-port-80-started-with-HTTP.  It's obviously the
> normal use of CONNECT.
>
>   
>>> Well, HTTP proxies are often available when nothing else is.
>>>       
>> Agreed, which places HTTP in a fairly unique position.
>>     
>
> Going further, I notice that CONNECT is sometimes not available, so a
> really robust tunneller must use the POST+GET method.
>
>   
>> Actually it's very common for CONNECT to be used for HTTPS.  Many people
>> prefer to not provide NAT to all users.  
>>     
>
> These days, why wouldn't they just NAT only port 443?  Using a CONNECT
> proxy seems to add nothing by way of security compared with
> port-restricted NAT, and just means server load and bigger latency.
>   
there are some things you can do intercepting port 443 sequenced data 
(i.e. up the TCP stack).  Such as checking higher level protocol (i.e. 
make sure it's SSL/TLS), checking certificates, and certificate 
revokation lists.  These aren't easy to do in NAT.

> On the face of it, I suspect CONNECT is still used for port 443 only
> because it dates from a time when port-restricted NAT (or any NAT)
> wasn't really an option.
>   
There are still plenty of security reasons why many people prefer not to 
offer NAT on their networks.

There are still plenty of people that think NAT is an abomination since 
it "breaks" TCP.  Most customers don't care about that sort of thing 
though, and for them it comes down to security/control issues.

I would have thought in the end, if someone is designing a new client 
server protocol, a good option would actually be to just use HTTP 
directly.  Most media players for instance support an HTTP mode.

although sometimes it goes a bit far, like UPnP - Soap over XML over 
HTTP over... wait for it.... multicast UDP...
> -- Jamie
>   

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

Received on Friday, 1 February 2008 20:42:49 UTC