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

RE: CONNECT message including tunneled data

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Fri, 01 Feb 2008 15:17:25 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: "'Jamie Lokier'" <jamie@shareable.org>, "'Robert Siemer'" <Robert.Siemer-httpwg@backsla.sh>, ietf-http-wg@w3.org
Message-Id: <1201875445.5827.44.camel@hlaptop>
fre 2008-02-01 klockan 16:35 +1300 skrev Adrien de Croy:
> > POST :-)
> back and forth and back and forth and back and forth etc etc with a
> single command and response?

Yes, if the intermediaries support forwarding of the response while
still sending the request.

If not then two requests is used, one POST and one GET, and application
logics to bind the two connections together at the application.

> I would have thought it would be easier to use CONNECT :)

True. But the split POST/GET approach do provide some transport benefits
which may be useful..

> > OH, I'm not advocating changing CONNECT itself.  The method name is
> > hard-coded into every proxy; the semantics cannot be changed.  Any new
> > strategy would need to use a new method name, at least.
> OK, which begs the obvious question - does this belong in HTTP?  We
> could re-implement SOCKS5 over HTTP, but why would we?

Agreed. SOCKS5(+) is already there, and  with support in very many
clients and covering the area of generic proxying pretty well.

> Sounds like you're proposing a fairly radical departure to the current
> target goal of HTTP.  Whilst I'd love to see HTTP move to a more
> state-driven multi-transactional multiplexed command protocol, it would
> no longer be or bear any resemblance to HTTP.  You'd need to assign a
> new port number for it :)

Or run it over SCTP.

> Some of these discussions should be kept in mind when looking to design
> HTTP 2.0



Received on Friday, 1 February 2008 14:18:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC