Re: Question on HTTP 408

This seems somewhat unclear. In our original server implementation the 
408 was returned after an idle connection was closed. However there was 
a bug report that some client got this wrong so this was changed to only 
return 408 when at least one byte was received and otherwise to just 
close the connection.

 From the last sentence in the cited text from p2 I would say to return 
a 408 on an idle connection is allowed even when no byte was received. 
If you bind to such a connection as a client, send your request and then 
read the 408 you are free to open a new connection and repeat the 
request. The same would happen if there is a real race condition.

Roland


On 03.06.2014 02:16, William Chan (???) 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
>         <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.