W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Proposal: 205 Bodies [#88]

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 26 Oct 2010 18:24:33 +0200
To: Adrien de Croy <adrien@qbik.com>
Cc: Daniel Stenberg <daniel@haxx.se>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20101026162433.GC11819@1wt.eu>
On Tue, Oct 26, 2010 at 11:06:18AM +1300, Adrien de Croy wrote:
> I imagine it's fairly common to get chunked bodies on 407 response 
> messages regardless of the request method.
> So I guess I take it back about whether chunking should be allowed, but 
> I still suggest bodies should be disallowed.

The only problem is with the 200 response. We could insists that this specific
code does not allow any body.

> The other non-standard thing about CONNECT is the reusability of the 
> connection, and connection state management.  For instance, is it 
> required for all successful responses to CONNECT to specify Connection: 
> close? Since that's the only way to specify that the connection cannot 
> be used for anything else afterwards, which we all know is actually the 
> case, since HTTP framing is lost as soon as the response message is 
> completed.

It's not the only way, because the lack of a content-length and
transfer-coding also implies the close.

In haproxy, I solved the issue differently. I don't consider the connection
is reusable or anything else, the connection switches to a "tunnel" mode
once it has been confirmed with the 200. The "tunnel" mode is a bidir TCP
stream. Considering that we rely on close would imply that we consider
messaging, but messaging does not necessarily mean that the data can flow
in both directions. If we didn't have existing implementations, I would
even not be shocked to consider that we forward bodies in both directions
up to their content lengths, and that after those bodies (end of messages
after all), the connection becomes bidirectional. Doing that now would be
scary though.

Received on Tuesday, 26 October 2010 16:28:15 UTC

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