Re: more HTTP timeout comments

On Fri, Mar 11, 2011 at 2:01 PM, Mark Nottingham <mnot@mnot.net> 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:
>
> > 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/
>
>
>
>
>