Re: Question on HTTP 408

On 5/06/2014 9:58 a.m., Willy Tarreau wrote:
> On Wed, Jun 04, 2014 at 10:46:05PM +0200, Daniel Stenberg wrote:
>> On Wed, 4 Jun 2014, Willy Tarreau wrote:
>>
>>> I'd go further, do you think we could improve the client's ability to 
>>> safely retry if a 408 was also emitted on persistent connections *after* a 
>>> request/response was already served ?
>>
>> You mean as a second response? That would effectively kill the connection 
>> for curl at least (without even reading the response) since it'll consider 
>> data on a connection it wants to re-use as a sign of badness and just close 
>> it.
> 
> Yes that was the idea.
> 
>>> I agree we need to find a consensus and better document these corner 
>>> cases. Most commonly deployed clients, servers and intermediaries are on 
>>> this list, so it should not be too hard to know what to change where :-)
>>
>> It is also important to remember that many of us have very old code bases 
>> still alive and in use out there so what we change now can easily break 
>> things we wrote a decade ago that still is being used...
> 
> Sure, I'm well aware of this and that's precisely because I'm not fond of
> breaking what works that I've been hesitating to change the way 408 is
> currently emitted by haproxy. It's been this way for 12 years I think,
> so who knows how many issues will surface if we start not sending 408
> anymore. At least I guess from Sebastien's report that some of his
> deployments will definitely break.
> 
> But if we can all together find the safest compatibility use case between
> most or even all products, we could hope to smoothly improve our respective
> next versions.


I'm pretty sure the experience Chrome had is a good example of how such
old/naive software will react. A switch of some FIN/RST from whatever
error handling to act as they would to a 400 reply, and other FIN/RST as
they would garbage+close. Disambiguating and allowing better
troubleshooting in the process.

If the old client is not handling unexpected 408 properly as alternative
to FIN/RST. Then its already not operating as per spec. The requirement
for garbag+FIN on unexpected *bytes* has nothing specifically to do with
those bytes being an early 408.

Amos

Received on Thursday, 5 June 2014 04:08:43 UTC