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

Re: Question on HTTP 408

From: Michael Sweet <msweet@apple.com>
Date: Tue, 03 Jun 2014 07:54:18 -0400
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Willy Tarreau <w@1wt.eu>, Matt Menke <mmenke@chromium.org>
Message-id: <13EF864C-1236-4497-BDE0-08403AA67379@apple.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>

This sounds like a pretty obvious bug - a HTTP server only responds when it has received something.  The usual keep-alive timeout of connections is silent (server just closes the connection, with a preceding TLS shutdown for HTTPS).

On Jun 2, 2014, at 8:16 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> Hello folks,
> Here's the relevant text from p2 (http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-6.5.7):
> 6.5.7.  408 Request Timeout
>    The 408 (Request Timeout) status code indicates that the server did
>    not receive a complete request message within the time that it was
>    prepared to wait.  A server SHOULD send the close connection option
>    (Section 6.1 of [Part1]) in the response, since 408 implies that the
>    server has decided to close the connection rather than continue
>    waiting.  If the client has an outstanding request in transit, the
>    client MAY repeat that request on a new connection.
> Server operators using HAProxy have filed a bug report with Chromium due to our lack of support for 408 (https://code.google.com/p/chromium/issues/detail?id=377581). We're going to fix that. 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.
> Currently, Chromium's connection management code treats this as a server bug, since when we bind a HTTP transaction to an idle connection, we expect that the connection does not have any buffered read data (since the previous transaction, if any, should have completed successfully). However, there's a race condition here, since the server may have terminated that idle connection with a 408 HTTP response followed by a FIN.
> There's fundamentally a race here, which is crappy and we fix in HTTP/2 with GOAWAY on the connection. My question here is, is it kosher for HAProxy to be doing this? In retrospect, I feel like it's a pragmatic decision for them to do so. That said, it feels incredibly ugly for an HTTP/1.X server to generate responses without a request. It's not completely clear to me what the intent is in the spec here, because it says that the 408 means the server did not receive a complete request. If it only receives a partial request, then that makes sense it could send a timeout. But if there's no request whatsoever, it's not immediately obvious to me that the spec says that that is allowed.
> I'm curious if any other implementers have thoughts here. Would love to hear them.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 3 June 2014 11:54:50 UTC

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