Re: CONNECT message including tunneled data

Adrien de Croy wrote:
> With CONNECT, the purpose is to establish a TCP connection.  There's no 
> guarantee what protocol will be used over the connection. 
> 
> I don't see how having an entity body on request or response can help 
> the goal of setting up a connection.  It is obviously subsequent data.  
> In no other place in HTTP do we consider sending entity data for a 
> subsequent request on an initial message,

I don't agree that it's "obviously subsequent data".  I think that
depends on the application and on your point of view.

Consider an app which uses CONNECT to establish a temporary Telnet
session.  Following CONNECT, the client transmits a single unix shell
command.  The response is the output of that command, and then the
connection closes.

Similar patterns are used with other request/response protocols like
rsync-over-CONNECT (sends a command to fetch a file, gets the file
back, or sends a command to get a file listing, gets the listing
back).

>From one point of view, the CONNECT is a separate operation.

But it's equally reasonable to see the CONNECT as just the initial
part of an application request, which happens to be wrapped in a
CONNECT as its mechanism.

The operational consequences of CONNECT that I see are:

   - One extra TCP/IP round trip, because you have to wait for the 2xx
     response before transmitting the subsequent request data.

   - Cannot re-use the HTTP connection after the application protocol
     has finished with it.

   - Combination of the above: cannot pipeline multiple application
     requests, if they need to use separate connections.  (See this
     already with rsync-over-CONNECT).

The logical consequence of CONNECT that I see is:

   - It's one more special case in the HTTP message boundary rules,
     which was never necessary but it's history is quite understandable.

When the operation effects are significant, it's possible to use POST
with overlapping request/response to get better performance, which
seems to be allowed, but only works with known client/proxy/server
combinations, and of course isn't a standard method.

> and I would be opposed to adding that capability now.

Certainly I would be opposed to changing CONNECT now - it would break
everything :-)

[ However, if there's any interest in developing "next generation"
HTTP (which ought to have gracefully degrading long message
multiplexing, response reordering, and two-way requests), I would
suggest that two-way streaming _inside_ messages would be quite a
natural fit for that. ]

-- Jamie

Received on Thursday, 31 January 2008 10:23:31 UTC