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

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