Re: FYI: http timeout headers

On 11/03/11 11:57, Robert Collins wrote:
> On Fri, Mar 11, 2011 at 11:16 AM, Mark Nottingham<mnot_at_yahoo-inc.com> wrote:
>> 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'm not sure whether that will happen, hence my question. I'm even less sure about the use cases for request-timeout, for the reasons you mention.
>
> I suspect that this is overengineering : scalable proxies really
> shouldn't need special handling for very long requests, and proxies
> that need special handling will still want timeouts to guard against
> e.g. roaming clients leaving stale connections.
>
> Simply recommending that intermediaries depend on TCP to time out
> connections might be sufficient, simpler, and allow room for clean
> layering to deal with roaming clients and the like without making
> requests larger.
>
> -Rob

  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

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.5