W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: more HTTP timeout comments

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 21 Mar 2011 13:21:14 +1100
Cc: Greg Wilkins <gregw@webtide.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D1C9A5DF-7440-4CCB-8EE3-D02DFF4475C2@mnot.net>
To: "Thomson, Martin" <Martin.Thomson@commscope.com>

On 18/03/2011, at 11:05 AM, Thomson, Martin wrote:
>> As many have said, connection-timeout already exists, as a keep-alive 
>> parameter, and even then it's not clear-cut.
> This is exactly the sort of discussion I wanted to have on this.  In looking at Keep-Alive I discovered that standardizing it might be difficult.  Without doing a wider survey, what I found was that Keep-Alive is used by only a few server and one client implementation (that I'm aware of).  According to http://www.http-stats.com/Keep-Alive, a few other servers send it, but there aren't that many sites using it.
> Reconciling the differences might be worth looking into:
>  Firefox sends Keep-Alive: 115
>  Apache sends Keep-Alive: timeout=15, max=100 (or similar)
> Particularly if it's being used already.  If it isn't already being used (as suggested below), then there is little harm in having a new header that is ignored as well.
> The draft authors haven't really concluded on Connection-Timeout vs. Keep-Alive either.

OK, good to know. Just FYI, HTTPbis already has:
... so there needs to be some coordination here. As that ticket states, Keep-Alive is already defined by

which simplifies the FireFox vs. Apache issue. I've just raised a bug with Mozilla:

> When you say:
>>>> Right. I think the authors hope that intermediaries (proxies and 
>>>> gateways) will adapt their policies (within configured limits) based
>>>> upon what they see in incoming connection-timeout headers, and
>>>> rewrite the outgoing connection-timeout headers appropriately.
> I think that's far from what we are hoping to achieve.  The goal is merely to inform.
> When a server (or intermediary) sets a policy regarding idle connection timeouts, the intent is to have that policy conveyed to the client (or intermediary) so that the client can act on this information.  The "negotiation" that occurs is mostly just an exchange of policy information.  The agreed value is the lower of the two.

"agreement" sounds an awful lot like "negotiation". :)

> The advantage that a server gains is when a client specifies a timeout requirement that is lower than their own policy.  They can then (at their discretion) close the idle connection sooner than otherwise.

Won't the client just close it?

Mark Nottingham   http://www.mnot.net/
Received on Monday, 21 March 2011 02:21:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC