Re: Question on HTTP 408

Hi Roy,

On Tue, Jun 03, 2014 at 12:51:19AM -0400, Roy T. Fielding wrote:
> On Jun 2, 2014, at 8:16 PM, William Chan (?????????) <willchan@chromium.org> wrote:
> > 
> > But HAProxy uses 408s in an intriguing way that violates some of our architectural assumptions. Namely, HAProxy wants to shut down an idle connection, it sends a 408 irrespective of whether or not there was a HTTP request.
> 
> That's a bug (and a complete waste of bytes). In most cases, clients are not
> expected to read when there is no outstanding request, so that 408 will just
> sit around the buffers. Even if the client happens to send a request in
> flight such that it would be ready to read, it is more likely to get a TCP
> RST than see the 408.

Warning, it's not an idle connection, it's when waiting for the *first*
request of that connection. After the first one, when a persistent
connection is idle, it refrains from emitting it because the client is
supposed to retry.

> Most clients will assume that a closed connection after idle is due to a
> timeout.

But when a client sees a closed connection, it has no way to know if the
request was processed or not before the connection was closed. For example,
if the server crashes (classical cause of silent close), the exact same
behaviour will happen. And the client is not allowed to retry a non-
idempotent request then. So here the 408 is the only way to tell the
client that the request was not handled at all and is safe to retry.

> 408 is really for use as an error status in log files, more than
> anything else, or for communicating an upstream timeout.

I don't really agree, the text of the 408 is clearly meant for clients
and even says what they should do in this situation. And it happens
quite a lot over lossy networks such as 3G or WiFi where the time to
send a large request can easily reach multiple seconds under poor
radio condition, then informing the client it can safely retry seems
essential.

Don't get me wrong, I have nothing against leaving the 408 error empty
by default, but I really fear that we'd make the situation worse for
some clients which strictly comply with the spec. Hence this discussion
that William initiated so that we clarify what should be done in this
situation.

Willy

Received on Tuesday, 3 June 2014 05:37:18 UTC