W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: I-D Action:draft-loreto-http-timeout-00.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 9 Jul 2010 11:52:45 +1000
Cc: Salvatore Loreto <salvatore.loreto@ericsson.com>, Greg Wilkins <gregw@webtide.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <B87C6C80-6C04-4464-8A75-DBD632A14C08@mnot.net>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>

On 02/07/2010, at 3:07 PM, Thomson, Martin wrote:

> That's OK.  Put what you want in there.  It's an upper bound thing.  If the local implementation has a timeout, then it (as an intermediary that is aware of the header) can tweak the value downward.
> The value can be tuned.  Encounter a gateway timeout and you can adjust the time downwards.
> The problem we are attempting to address is the fact that the server is blind.  The server knows that you are long polling - because that's the way that most long-polling resources are setup. What they really want to know is how long to wait before sending their 304 if nothing changes.  We want to remove that guesswork.
> Obviously, you can't just remove it straight away, because intermediaries don't help out.  You have to rely on the client tuning the timeout.  In the end-game, the client doesn't have to.  That's the aim.
>> All of this leads me to believe that there's little value in setting a
>> timeout; what we really need is just a flag that says "I'm long-polling
>> here." It's a lot easier to implement support for this (e.g., in Squid,
>> Apache Traffic Server, elsewhere), and more difficult for it to cause
>> problems.
> If you don't accept that intermediaries can change, then I'd be inclined to agree.  If that one bit is all that intermediaries get from the header, then we probably haven't helped a lot.  That said

They can change, but I don't see the incentive for them to change here. From an intermediary's perspective, the most useful thing here is to have a separate policy for requests that are long polling. Beyond that, rewriting headers is a pain; remember that intermediaries are very performance-sensitive. 

Also, the rate of change for intermediaries is a *lot* slower than that of clients or servers; many are in hardware, and many are no longer supported by vendors (unfortunately). I suspect clients will have to keep an eye on the timeout for a *long* time -- on the sort of timescale where just using websockets/spdy/waka/[insert proposal here] becomes more attractive. 


Mark Nottingham     http://www.mnot.net/
Received on Friday, 9 July 2010 01:53:18 UTC

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