- 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>
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. Regards, Willy
Received on Tuesday, 26 October 2010 16:28:15 UTC