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

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 2 Jul 2010 13:07:18 +0800

> From: Mark Nottingham [mailto:[email-masked]]
...
> 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.

--Martin

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Jul 2010 11:52:45 +1000

> 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. 

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Jul 2010 13:50:00 +0800

> > 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.

Right - for the cases you have in mind, the single bit might be wasted bytes too.

However, in the context of XmlHTTPRequest, might we not consider the browser to be an intermediary?  Would the same constraints apply there?

This leads to the role of the client.  The client is also in a position to tune this value so that the server gets the info they need.  The client (or browser-side "intermediary") can look for dropped connections or 504 responses and tune timeouts downward accordingly.

--Martin

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Jul 2010 17:43:12 +1000

> Right - for the cases you have in mind, the single bit might be wasted bytes too.

Not really. Patching Squid (etc.) to change policy based upon the presence of a header isn't a big deal, and when it's deployed as an accelerator, the single bit could be quite valuable.

> However, in the context of XmlHTTPRequest, might we not consider the browser to be an intermediary?  Would the same constraints apply there?

Are you suggesting that the browser rewrite headers before handing them to the HTTP API? That's likely to cause a fair amount of confusion... Why not just expose the connection timeout of the browser as an API extension?

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 09 Jul 2010 13:34:37 +0300

> Not really. Patching Squid (etc.) to change policy based upon the presence of a header isn't a big deal, and when it's deployed as an accelerator, the single bit could be quite valuable.
if I understood correctly Mark, you are to suggesting that just having 
an header would be enough and much easier to implement for the 
intermediaries, isn't it?
if so I don't see much difference in defining an header containing a 
value and let the intermediate decide if consider or not the value and 
then use it as a single bit!

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2010 09:58:10 +1000

On 09/07/2010, at 8:34 PM, Salvatore Loreto wrote:
> 
> if I understood correctly Mark, you are to suggesting that just having an header would be enough and much easier to implement for the intermediaries, isn't it?
> if so I don't see much difference in defining an header containing a value and let the intermediate decide if consider or not the value and then use it as a single bit!

True, except that -- as I said before -- I think many implementers are going to misinterpret this header; because they're not used to using proxies and distributed systems, its semantics are quite subtle, and possibly dangerous (i.e., it will leave them in a place worse off than before). 

Cheers,