- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 19 Jul 2012 00:09:10 +0200
- To: Osama Mazahir <OSAMAM@microsoft.com>
- Cc: Roberto Peon <grmocg@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Adrien de Croy <adrien@qbik.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, Jul 17, 2012 at 10:32:58PM +0000, Osama Mazahir wrote: > It's not broken as long as we are OK that the connection has to be closed > upon expectation rejection (for non-chunked entity-body). > > Based on my understanding, the client must close the connection if the server > replied with a 4xx [1] against a non-chunked request. Which makes sense as > it ensures message integrity on a persistent connection [2]. Essentially, we > break the ambiguity by having the server assume that the next byte (after the > CRLFCRLF) will be entity-body. You're right indeed, the protocol is broken in this case depending on whether the client gets the 4xx in time and refrains from sending the body, or if it starts sending the body before receiving the 4xx. The protocol does not allow us to tell what the server will get depending on the timing (either body or next request). I think we should state that upon 4xx in response to Expect: 100-Continue, the server should close the connection (after draining possibly pending data), just as it would do on a redirect to another domain for instance. That's an interesting case. I don't know how haproxy handles it, I suspect it could be tricky. Regards, Willy
Received on Wednesday, 18 July 2012 22:10:06 UTC