W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Question on HTTP 408

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 4 Jun 2014 23:58:47 +0200
To: Daniel Stenberg <daniel@haxx.se>
Cc: "William Chan (?????????)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Matt Menke <mmenke@chromium.org>
Message-ID: <20140604215847.GJ3154@1wt.eu>
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.

Regards,
Willy
Received on Wednesday, 4 June 2014 21:59:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC