W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

RE: I-D Action:draft-loreto-http-timeout-00.txt

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Fri, 9 Jul 2010 13:50:00 +0800
To: Mark Nottingham <mnot@mnot.net>
CC: Salvatore Loreto <salvatore.loreto@ericsson.com>, Greg Wilkins <gregw@webtide.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCCD04@SISPE7MB1.commscope.com>

> > If you don't accept that intermediaries can change, then I'd be
> inclined to agree.  If that one bit is all that intermediaries get from
> the header, then we probably haven't helped a lot.  That said
> They can change, but I don't see the incentive for them to change here.
> From an intermediary's perspective, the most useful thing here is to
> have a separate policy for requests that are long polling. Beyond that,
> rewriting headers is a pain; remember that intermediaries are very
> performance-sensitive.
> Also, the rate of change for intermediaries is a *lot* slower than that
> of clients or servers; many are in hardware, and many are no longer
> supported by vendors (unfortunately). I suspect clients will have to
> keep an eye on the timeout for a *long* time -- on the sort of
> timescale where just using websockets/spdy/waka/[insert proposal here]
> becomes more attractive.

Right - for the cases you have in mind, the single bit might be wasted bytes too.

However, in the context of XmlHTTPRequest, might we not consider the browser to be an intermediary?  Would the same constraints apply there?

This leads to the role of the client.  The client is also in a position to tune this value so that the server gets the info they need.  The client (or browser-side "intermediary") can look for dropped connections or 504 responses and tune timeouts downward accordingly.

Received on Friday, 9 July 2010 05:48:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:54 UTC