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

Re: I-D Action:draft-nottingham-http-pipeline-00.txt

From: Patrick McManus <mcmanus@ducksong.com>
Date: Tue, 31 Aug 2010 10:33:58 -0400
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1283265238.2404.1175.camel@tng>
On Tue, 2010-08-31 at 15:53 +1000, Mark Nottingham wrote:

> Good question. While we could run some studies against top100 Web
> sites, etc., it would IMO be more useful if we could get some stats
> from implementations that do use pipelining; namely, Opera and Mozilla
> (when enabled). 
> I wonder how feasible it would be to have them collect stats (e.g., #
> of reqs successfully pipelined, average pipeline length, pipeline
> errors broken down by type) and have the user opt into them being sent
> to a server.

its a little off topic, but mozilla has been having a discussion on
their platform list regarding stats collection and the value of
characterizing the web in general. fyi:


> False positives are a concern, but at worst pipelining wouldn't work
> in those cases; i.e., the Web site still would, so it would be a
> "soft" failure.

well, the transaction presumably has to be redone in a non pipelined
context so there is a real cost to the false positive. But yes, it
doesn't really break anything so the only important question is how
often would it happen? My gut says it would happen a whole lot more
often than actual pipelining errors happen - especially because server
operators wouldn't have good visibility into it even occurring and it
seems the conditions for the origin-server and the user-agent to have
different views of the URI are common enough.

> What I'm trying to do is create some aids to pipelining deployment that might even be temporary 

+1 !

(re md5)
> If so, I don't think it provides everything that assoc-req does; it doesn't tie the response to its associated request.

you're right. For a moment, I had my head wrapped around headers and
bodies being mismatched rather than requests and responses.

> > Also along those lines, md-5 plays well with proxies. Assoc-req makes my
> > head hurt - the draft says proxies should never generate assoc-req (and

> Why does Assoc-Req make that hard?

A week's mulling has mellowed me on this point.. but I'm reacting to
assoc-req being only generated on the origin server, but pipelines
potentially being added and removed at various hops. Origin is optimal,
sure, but isn't it still valuable if a proxy adds the response header as
long as it doesn't already exist - it is matching the request and
response as close to the origin as something that supports it is capable
of doing... 
Received on Tuesday, 31 August 2010 14:34:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 1 February 2023 02:17:43 UTC