- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 17 Jul 2012 23:04:37 +0200
- To: Willy Tarreau <w@1wt.eu>
- CC: Osama Mazahir <OSAMAM@microsoft.com>, 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 2012-07-17 22:59, Willy Tarreau wrote: > On Tue, Jul 17, 2012 at 10:31:08PM +0200, Julian Reschke wrote: >> On 2012-07-17 21:45, Osama Mazahir wrote: >>> As it is currently, 100-continue is problematic. The situation is >>> tricky because the client is not forced to wait for the 100/417/4xx >>> (i.e. client is allowed to timeout and send the entity body). Thus, the >>> server does not have a deterministic way to now if the next byte after >>> the double CRLF is the first byte of the next request or the first byte >>> of the entity body (of the initial request). This results in >>> connections getting closed in various edge/error cases. >>> >>> 100-continue is almost there but if we wanted to use it in a robust >>> manner in HTTP2 then I think we would have to revisit its specification. >>> ... >> >> Well, we are revising RFC 2616, and if something is broken here we >> should consider to fix it. Or, minimally, document the problem. >> >> If I understand correctly, this will happen if the client sends "Expect: >> 100-continue", the server is slow to return an error status, and the >> client decides to give up waiting for the 100 status, and continues? > > I don't see how it is possible to send a next request without first sending > the entity body, the message is not complete until it has been sent as a > whole; the problem could only happen if the server wished to reject the > expectation (4xx). Exactly. So why, *in practice*, would it take the server so long to return the 4xx? (Just trying to understand whether this is a problem in practice, and if it is, what we could do about it -- recommend a minimal timeout?) Best regards, Julian
Received on Tuesday, 17 July 2012 21:05:08 UTC