usability of 100-continue, was: HTTP2 Expression of Interest : Squid

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