Re: Question on HTTP 408

William,

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