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

Clients want to have small timeouts when possible, partially because of
poor behavior of NATs when they lose the mapping and begin black holing
traffic.
Its all a race.
-=R
On Tue, Jul 17, 2012 at 2:04 PM, Julian Reschke <julian.reschke@gmx.de>wrote:
> 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
>
>
>