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

Question on HTTP 408

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Mon, 2 Jun 2014 17:16:30 -0700
Message-ID: <CAA4WUYgEWo4UMj+3=CO=d8NV5aUdirKe0zR1YEik_KQVkqabCQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, Willy Tarreau <w@1wt.eu>, Matt Menke <mmenke@chromium.org>
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 <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-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
<http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#ref-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.
Received on Tuesday, 3 June 2014 00:16:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:26 UTC