- From: 陈智昌 <willchan@chromium.org>
- Date: Mon, 2 Jun 2014 17:16:30 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>, Willy Tarreau <w@1wt.eu>, Matt Menke <mmenke@chromium.org>
- Message-ID: <CAA4WUYgEWo4UMj+3=CO=d8NV5aUdirKe0zR1YEik_KQVkqabCQ@mail.gmail.com>
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