W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: CONNECT command with message body

From: Jamie Lokier <jamie@shareable.org>
Date: Tue, 5 May 2009 12:52:35 +0100
To: Daniel Stenberg <daniel@haxx.se>
Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20090505115235.GA25328@shareable.org>
Daniel Stenberg wrote:
> Sorry, but can you clarify how you would read that paragraph to get that 
> meaning out of it? (I'm not suggesting you think this, I just don't see how 
> it can be intrepreted that way.)
> 
> Here's that last paragraph of RFC2817 5.2 with my comments:
> 
>    Like any other pipelined HTTP/1.1 request, data to be tunneled may be
>    sent immediately after the blank line.
> 
> This seems to be like it's saying that everything after the blank line is 
> tunneled. And it also mentions pipelining (in a funny way if you ask me), 
> which only works for requests with no request-bodies.

Pipelining works (in principle) for requests with request bodies too.

They just need to be idempotent requests, because you might not know
if the request succeeded when the connection is dropped.  Which is
probably why pipelining is never used with anything other than HEAD
and GET in practice.

The spec reads to me like a client can send CONNECT followed by data
to be tunnelled immediately if the CONNECT is successful.

>    The usual caveats also apply: data may be discarded if the eventual
>    response is negative, and the connection may be reset with no response if
>    more than one TCP segment is outstanding.
> 
> Is it that "data may be discarded" part? It's not clear to me what data 
> this refers to.

See RFC2616 8.2.2 "Monitoring Connections for Error Status Messages".

If you have a request with a body, and the response is an "error" (I
could never decide if 3xx counts as an error for this), the server is
allowed to send the error response before receiving the whole request,
and the client is allowed to abort the request when it sees the error
response.  If it does abort and it isn't a chunked request, the client
must close the connection at that point because the client and
server's request parsing is no longer synchronised.

If the intention is that you can send CONNECT followed by data to
tunnel immediately, and the CONNECT response is an error, it would be
just like other pipelined requests with body: because it isn't
chunked, the client must close the connection.

Note the server should _not_ close the connection immediately after
sending the error response, because the client will often not see the
error response if there is data in flight from the client to the
server, because that triggers a TCP reset.  The server could
half-close the TCP connection, but HTTP doesn't talk about half-closed
TCPs (it probably should).

-- Jamie
Received on Tuesday, 5 May 2009 11:53:16 GMT

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