- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 20 Jul 2012 19:28:47 +1200
- To: Willy Tarreau <w@1wt.eu>
- CC: Osama Mazahir <OSAMAM@microsoft.com>, 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>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 20/07/2012 6:02 p.m., Willy Tarreau wrote: > On Fri, Jul 20, 2012 at 12:32:11AM +0000, Osama Mazahir wrote: >>> 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. >> I think the current state is fine. The current text says "If it responds >> with a final status code, it MAY close the transport connection or it MAY >> continue to read and discard the rest of the request." Windows tries to >> leave the connection open (i.e. of course, upper layer can always override or >> we may have hit an non-continuable error such as corrupted request). This >> allows the server to handle the following cases: >> 1) Client sent the entity-body before getting the expect-answer (e.g. timeout). >> 2) Client believes it is more efficient to send irrelevant entity-body >> instead of tearing down and warming up a new connection. >> 3) Client was sending a chunked entity-body and can gracefully indicate >> request end with a zero chunk. > But it does not cover the client which immediately receives the 417 and > which refrains from sending and instead reuses the connection. Did you mean the tricky case where encoding is attempted and the 417 returns. For chunked the server does not support detecting a zero-length chunk as an aborted entity. But the client requires it to keep-alive. So the option there is client closure if it arrives late and server required to assume the next bytes after header are a new header set. Note that a zero-length chunk is "0CRLF" which is not a valid HTTP request-line even when assuming HTTP/0.9 compatibility. The other transfer encodings result in binary data which is also not valid request-method. The server aborting the connection on invalid next-request seems to take effect in that case regardless of encoding. When the race is lost the server barfs and closes. When the race is won the client goes right to next request and the keep-alive works fine. The key though is for the client to *always* continue with the attempted operation on a timeout. If the server does not reject it fast enough too bad. Could we mandate a minimum client timeout suitable for slow high latency connections. Or suggest that it is linked to RTT somehow? as you say it is RTT related race, making a timeout depend on RTT seams reasonable if possible. > It is all a matter of race condition : depending on the RTT between the > client and the server, the exact same sequence of operations at both sides > may lead to a different behaviour : > - only headers are sent, client does not send body and goes on with next > request ; > - body starts to be sent and server has to drain it. > > So the server cannot detect whether what follows is a body or a next > request. > > I suspect that sending request-looking data in a POST with an Expect > header might produce interesting results which merit being studied on > various products : > > POST /public HTTP/1.1 > Host: www.example.com > Expect: 100-Continue > Content-Length: 100 > > GET /private HTTP/1.1 > Host: www.example.com In the above example the use of content-length requires that the server drain 100 bytes regardless of what the client does. > In my opinion the only way to remain safe would be to systematically > close the connection after a 4xx. However it could cause problems with > connection-based authentication such as NTLM. It does not look like a > trivial problem. On NTLM the initial www-auth scheme advertisement can safely be closed. It's inefficient but safe. The first handshake responses is where trouble comes in, and by that time the client should have stopped attempting Expect. Amos
Received on Friday, 20 July 2012 07:29:27 UTC