Subject: more HTTP timeout comments

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Mar 2011 14:01:27 -0800

I'm CC:ing httpbis on this round of feedback rather than hybi for the time being, as I think the bulk of implementers that this proposal impacts are here, rather than there.

My previous comments for reference: <http://www.ietf.org/mail-archive/web/hybi/current/msg06859.html>

In particular, I don't see the use case for Request-Timeout, and suspect it may be actively harmful, or at least an attractive nuisance. 

As many have said, connection-timeout already exists, as a keep-alive parameter, and even then it's not clear-cut.

Finally, I'd like to highlight some more feedback from the Squid-dev community <http://www.squid-cache.org/mail-archive/squid-dev/201103/0095.html>, courtesy of Amos Jeffries:

> I think Squid has not traditionally obeyed the TTLs in Keep-Alive: 
> anyway. Which is part of where this problem arises.  I may be wrong, 
> through I did not see any such timeout code when changing the pconns 
> recently.
>  Patches to make IdleConnList obey Keep-Alive headers which are 
> already being sent by many sites would be welcome.
> 
> 
> The tricky bits as Robert said come when desired TTL is longer than 
> Squid config TTL. Providing an HTTP control to force it longer will not 
> be accepted lightly by the site admins and will lead to calls for yet 
> another violation override-* directive which makes the whole system and 
> standard useless and worse; leas to false expectations.
> 
> 
> Also, what happens once Squid obeys both?
>  Keep-Alive: 300
>  Connection-Timeout: 3600
> 
> I like the idea of the timeout applying to upgraded requests despite the 
> data transferred (and by extension CONNECT). It means we can cut 
> connections at X seconds even if there are bytes flowing still or 
> recently. (Reading the words as stated, they might not have foreseen 
> that interpretation).
> 
> Though I fail to see where the timeouts would not more reasonably be 
> accomplished by standard parameter definitions for Keep-Alive.
> 
> IMHO they would be better defining params for the Keep-Alive: and 
> Expect: headers. Such that the client can "Expect: keep-alive" with some 
> TTL Keep-Alive: values. Any knowing step in the chain can 417 it with 
> failure details, or the thing can succeed and acts as they desire.
> 
> 
> /rant warning/
> 
> Off the topic of this draft. It references long-polling being cut as one 
> of its basic problems being solved.
> 
> Firstly I've been reminded repeatedly that there are numerous networks 
> where the admin is penalized if a request takes more than X 
> milliseconds. Implications there are clear.
> 
> Secondly are my own experiences with certain sites. These channels 
> long-poll for hours! When the game player is not present they just 
> continue until cut. Several such channels are open at any given time 
> from a single page, greatly restricting the browsers few 
> connections-per-proxy. The long-poll itself is the cause of many slow 
> client experiences to my knowledge.
> /rant

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

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 11 Mar 2011 18:05:40 -0800

On Fri, Mar 11, 2011 at 2:01 PM, Mark Nottingham <[email-masked]> wrote:

> I'm CC:ing httpbis on this round of feedback rather than hybi for the time
> being, as I think the bulk of implementers that this proposal impacts are
> here, rather than there.
>
> My previous comments for reference: <
> http://www.ietf.org/mail-archive/web/hybi/current/msg06859.html>
>
> In particular, I don't see the use case for Request-Timeout, and suspect it
> may be actively harmful, or at least an attractive nuisance.
>
> As many have said, connection-timeout already exists, as a keep-alive
> parameter, and even then it's not clear-cut.
>
As a server implementer, I too find request timeout hardly useful, although
it's typically supported in some adhoc way. What's really missing is a
reliable way for clients or proxies to cancel an in-flight request, and a
declarative timeout won't offer too much help in solving such a problem.

- Wenbo

> Finally, I'd like to highlight some more feedback from the Squid-dev
> community <
> http://www.squid-cache.org/mail-archive/squid-dev/201103/0095.html>,
> courtesy of Amos Jeffries:
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 18 Mar 2011 08:05:42 +0800

Hi Mark,

Thanks for looking at this.

On 2011-03-12 at 09:01:27, Mark Nottingham wrote:
> I'm CC:ing httpbis on this round of feedback rather than hybi for the 
> time being, as I think the bulk of implementers that this proposal 
> impacts are here, rather than there.
> 

I'll respond to your concerns about Request-Timeout over there.

> In particular, I don't see the use case for Request-Timeout, and 
> suspect it may be actively harmful, or at least an attractive nuisance.
> 

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.

> community <http://www.squid-cache.org/mail-archive/squid-	
> dev/201103/0095.html>, courtesy of Amos Jeffries:

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.

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.

> > Also, what happens once Squid obeys both?

That's a problem I'd like to avoid.  Using Keep-Alive does address that, as long as we conclude that doesn't cause problems.

> > I like the idea of the timeout applying to upgraded requests despite 
> > the data transferred (and by extension CONNECT). It means we can cut 

That is a use we didn't discuss.  Personally, I don't see what that really buys - on the contrary, that would seem to prevent connection re-use, which is one of the things we are trying to maximize with this proposal.

> > Expect: headers. Such that the client can "Expect: keep-alive" with 
> > some TTL Keep-Alive: values. Any knowing step in the chain can 417 
> > it with failure details, or the thing can succeed and acts as they
> desire.

Expect: headers will only ensure that the server indicates their policy.  This is useful, but the client still needs to send their own policy down the wire.  I see no point in having either client or server placing constraints on what the policy for other party is.

--Martin

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Mar 2011 13:21:14 +1100

> The draft authors haven't really concluded on Connection-Timeout vs. Keep-Alive either.

OK, good to know. Just FYI, HTTPbis already has:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/158
... so there needs to be some coordination here. As that ticket states, Keep-Alive is already defined by
  http://tools.ietf.org/html/rfc2068#section-19.7.1.1

which simplifies the FireFox vs. Apache issue. I've just raised a bug with Mozilla:
  https://bugzilla.mozilla.org/show_bug.cgi?id=643352

> 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 infor…

"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 ot…

Won't the client just close it?