RE: more HTTP timeout comments

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

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

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

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?
> >  Keep-Alive: 300
> >  Connection-Timeout: 3600

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

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.

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

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

Received on Friday, 18 March 2011 00:06:21 UTC