Re: Question on HTTP 408

this 408-reply without a request is odd but common. HA proxy isn't the only
server that does it - though I can't recall off the top of my head which
other one does it. Firefox has had code to cope for quite a while. For
better or for worse its definitely part of the http/1 cruft implementors
need to deal with that http/2 shouldn't be burdened by.



On Tue, Jun 3, 2014 at 7:54 AM, Michael Sweet <msweet@apple.com> wrote:

> 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 <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.
>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>