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 > > >
Received on Tuesday, 17 July 2012 21:12:58 UTC