W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: pipelined client/server behaviour

From: Adrian Chadd <adrian@creative.net.au>
Date: Sat, 31 Mar 2007 21:55:30 +0800
To: Eric Lawrence <ericlaw@exchange.microsoft.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <20070331135530.GA32386@skywalker.creative.net.au>

On Tue, Mar 27, 2007, Eric Lawrence wrote:
> My understanding is that Opera invested in heuristic detection to determine whether pipelining is supported by an upstream proxy or server.  I'm not sure if their algorithms are public.
> Trying to support pipelining is probably one of the biggest challenges I encountered in developing Fiddler.  Supporting pipelining in a user-agent is even more challenging, because you often must decide whether queueing a given request into a pipeline is likely to improve performance (vs using another connection) without knowing how large the remote file is and/or how long it will take to generate.

Looking at it from a basic intermediary perspective I'm tempted to suggest
"trust the client" when it comes to pipelining - if the client wishes to
pipeling requests then pipeline requests in the same fashion over the same
connection to the origin or next-hop intermediary. The trick here is trying
to preserve the "connectionness" of a client request (much like what must
be done for NTLM type authentication schemes to successfully pass through
an intermediary) which might be a little different to how people see things.

I'm sure smarter intermediaries could and do get their hands dirty as they
cross the line between intermediary and client (eg, pre-fetching intermediaries)
but I'm focusing on what a normal forward or reverse HTTP proxy would/should

What do you think? I think its worth trying to clarify this stuff.

Received on Saturday, 31 March 2007 13:44:52 UTC

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