more HTTP timeout comments

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/

Received on Friday, 11 March 2011 22:02:00 UTC