- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 17 Jul 2012 22:31:08 +0200
- To: Osama Mazahir <OSAMAM@microsoft.com>
- CC: 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 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? Best regards, Julian
Received on Tuesday, 17 July 2012 20:31:50 UTC