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

Re: Question on HTTP 408

From: Michael Sweet <msweet@apple.com>
Date: Wed, 04 Jun 2014 07:52:27 -0400
Cc: "William Chan (?????????)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Matt Menke <mmenke@chromium.org>
Message-id: <090B6662-635A-42A3-941C-C9D6CB24ACF4@apple.com>
To: Willy Tarreau <w@1wt.eu>

On Jun 4, 2014, at 12:42 AM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Michael,
> On Tue, Jun 03, 2014 at 07:54:18AM -0400, Michael Sweet 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).
> Please could you check my other response to Roy ? In short I do instead
> think that responding 408 is the only way to gracefully shut down *and*
> inform the client it can safely retry and I really think it was designed
> for this exact purpose.

I don't think it was designed for being returned when no request had started coming in, but rather when a partial request was received and then timed out.  There is nothing in any of the HTTP RFCs that talks about returning a response line, headers, and message body to the client without first receiving something from the client.

What CUPS does (and this was largely based on asking the question, "What does Apache HTTP Server do?" many years ago) is to silently close the connection after the configured timeout, which is large enough (300 seconds for CUPS and Apache) to account for any reasonable traffic delays (on the Earth, at least).

I can understand if you don't want to have as large of a timeout for a proxy that is shared by thousands of clients, but you can definitely make this configurable and default to something reasonable (30-60 seconds).  If the network connectivity is so bad that the request line and headers don't start flowing within that timeframe, then there is probably no point in retrying automatically anyways.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Wednesday, 4 June 2014 11:52:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC