W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: CONNECT message including tunneled data

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 1 Feb 2008 18:17:06 +0000
To: Adrien de Croy <adrien@qbik.com>
Cc: 'Robert Siemer' <Robert.Siemer-httpwg@backsla.sh>, ietf-http-wg@w3.org
Message-ID: <20080201181706.GC14032@shareable.org>

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).

> > 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.

> 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...

> 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 :-)

> > 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.

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.

-- Jamie
Received on Friday, 1 February 2008 19:48:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:36 GMT