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

> From: Mark Nottingham []
> First of all, the Timeout HTTP header field is already defined and
> registered:

Whoops :)

> I'm inclined to think that passing specific timeout values from the
> client to the server isn't useful, and sometimes dangerous (because it
> will encourage creation of race conditions). 

I don't buy that.  Race conditions are only a problem where there is a strict expectation about time.  In my experience, "soft" timing information of this sort is still valuable.  See below.

> The vast majority of
> intermediaries (whether HTTP, NAT, etc.) will NOT change this value
> according to their configuration, and so its value can't be trusted.
> For that matter, when set from some client tools (e.g., XHR), there
> won't even be any visibility into the local implementation's various
> timeouts; the value set will therefore be a shot in the dark.
> Furthermore, most client applications will want to set it for "a lot,"
> without having any more specific guidance.

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

> Regarding Connection-Timeout, why not just codify the Keep-Alive
> timeout parameter? It's already implemented in Apache (and others,
> IIRC).

Can do.  It was only late in the piece that we realized just how much Connection-Timeout looked like Keep-Alive.


Received on Friday, 2 July 2010 05:05:54 UTC