- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 20 Jul 2012 22:44:16 +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 7:52 p.m., Willy Tarreau wrote: > On Fri, Jul 20, 2012 at 07:28:47PM +1200, Amos Jeffries wrote: >>> 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. > no, see with the example below :-) > >> 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. > Application never have any idea of RTT, especially when they're behind > reverse-proxies. > >>> 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. > Exactly. The problem is that the client is not forced to send data on a > failed expectation (which is the purpose). Imagine with the example above : > > Client Server > -------------------- request headers ------------------------> > > <----------- 417 failed -------------------------------------- > > ------ no body, then go on with next request ----------------> > > Or : > > Client Server > -------------------- request headers ------------------------> > > ... <------ 417 failed --------- > ---------- tired of waiting, sending body -------------------> > <------ 417 failed ------ ... > > > In both situations, the server receives something after it has sent 417. > In one case it's the next request and in the other case it's the body. > It could be the same with 401 BTW. > > So after a failed expectation with a content-length, the connection must > not be reused. Chunked encoding does not have this issue however since > the end of the message is always known. That is still a content-length case though (absene of encoding type). Part 1 section 3.3.3 point #5. In all of those cases content-length amount of bytes MUST be sent or the connection aborted. 417 is a final response to that initial request. Therefore the server drains the content-length body and connection re-use can begin. Client is responsible for aborting the connection or padding with disposable garbage bytes. At no point can the client send content-length then re-use the connection earlier. Amos
Received on Friday, 20 July 2012 10:44:54 UTC