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

ons 2010-09-08 klockan 07:41 +0200 skrev Willy Tarreau:

> After the first request, the browser already knows it's worth trying
> to pipeline. After the pipelined requests, the browser has a confirmation
> that the server really supports pipelining. At this point it can simply
> stop emitting the header for this host.

Just one issue. The proposed negotiation schemes may fail if there is
any intermediaries, often indicating false negatives, but could also
indicate a false positive if the intermediary is broken but server
works.. and no, I don't see any alternative negotiation scheme that
really works.

A response header based on request-URI. Fails if there is intermediaries
rewriting the request-URI.

A request header echoed back in the response. Fails if there is any
caching intermediaries not knowing about this, unless you also prohibit
caching.

And any such approach requires support on both sides which seriously
holds back any deployment.


Is there any reasonable data about how common brokenness in pipelining
really is? I know some quite bad theoretical/mythical examples have been
mentioned in the discussions, but also have the feeling that those are
mostly exceptions and not at all common.

Just question if adding a negotiation for enabling pipelining is
worthwile, or if it's better to simply assume pipelining works unless
indicated otherwise and beat up the few who are found broken (and per
definition not compliant with any HTTP version, new or old)

Issue #4, hinting, is surely worthwhile to investigate and fully
independent of brokenness. But I think the opposite approach needs to be
taken here from what's discussed in the draft. Instead of hinting
"quick" there is need to hint "slow/blocking/large" indicating that
those objects should not be early in the pipeline. These hints are also
very much needed for deciding connection management in general and not
isolated to pipelining.

Regards
Henrik

Received on Saturday, 11 September 2010 23:21:33 UTC