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

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Sep 2010 10:34:42 +1000

On 01/09/2010, at 12:33 AM, Patrick McManus wrote:
>> 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.

True. However, it would happen once per server per (however long the browser can remember it; default is session, I suppose). 

Also, remember that this would only happen for those servers that choose to deploy the header, but get it wrong somehow (i.e., they don't adequately test). So, good testing / verification tools (which would be dead simple to produce) would mitigate this.

Finally, in most situations where URLs get munged, the appropriate place to generate this header is where the URL munging happens (i.e., in the gateway / reverse proxy / surrogate / CDN / accelerator / whatever they're calling them today). 

I agree it's not perfect (by a long shot), but I'm at a loss to come up with another way to do this that improves the situation *and* is compatible with the deployed architecture (i.e., doesn't require HTTP/2.0). 

One more thought -- one way to partially address these concerns would be to remove information from assoc-req; e.g., to only echo the path back, omitting the hostname/port, so that people who rewrite them won't get caught. This doesn't feel like the right thing to do to me, however.

>>> 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... 

Do you mean 'proxy' in the sense of one run by an ISP or other third party (i.e., without a relationship to the origin), or just intermediaries in general (as above)?

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 8 Sep 2010 07:41:38 +0200

Hi Mark,

> Also, remember that this would only happen for those servers that choose to deploy the header, but get it wrong somehow (i.e., they don't adequately test). So, good testing / verification tools (wh…

My fears are related to the way admins test their deployment. When I
see the number of times we encounter incorrectly rewritten Location
headers and the number of incorrect Apache rewrite rules, I'm pretty
sure that most of the times, this header will be wrong and since it
will not have a measurable effect, noone will notice it nor fix it.
It is even possible that some browsers will finally try to "fix" what
they get in the response to try to match what the sent (eg: strip
double slashes, ignore the host part, etc...).

> One more thought -- one way to partially address these concerns would be to remove information from assoc-req; e.g., to only echo the path back, omitting the hostname/port, so that people who rewri…

That's where I think that a short MD5 of the request would to the trick.
The client could emit it (just a few bytes, not the complete MD5), and
the other end (server, reverse-proxy, load balancer, etc... in fact the
first intermediary that knows it supports pipelining on the client side
but not the server side) would remove it from the passed on request and
echo it back. The two main advantages I see :

  - we're certain to get only one respose back because it's presented
    only when the header is seen in the request ;

  - it depends on the URL even if the intermediaries don't know the
    URL the client was requesting due to rewrites ;

And since you said it would be needed at the beginning of the requests
only (eg: once per Host header), sending just a few bytes in each first
request finally requires less bandwidth because once the client gets its
response, it doesn't need to request that anymore.

So we'd get something like this :

  Browser                               Server

GET /foo.html HTTP/1.1
Host: example.com
Assoc-Req: e62004f5    ------->
                                     HTTP/1.1 200 OK
                                     Content-length: 2346
                                     Content-type: text/html
                                     Assoc-Req: e62004f5
                       <-------

GET /img/foo1.png HTTP/1.1
Host: example.com
Referer: http://example.com/foo.html
Assoc-Req: 5b5e86b8

GET /img/foo2.png HTTP/1.1
Host: example.com
Referer: http://example.com/foo.html
Assoc-Req: 394e6c1c

GET /img/foo3.png HTTP/1.1
Host: example.com
Referer: http://example.com/foo.html
Assoc-Req: a69add09   --------->
                                     HTTP/1.1 200 OK
                                     Content-length: 151
                                     Content-type: image/png
                                     Assoc-Req: 5b5e86b8

                                     HTTP/1.1 200 OK
                                     Content-length: 152
                                     Content-type: image/png
                                     Assoc-Req: 394e6c1c

                                     HTTP/1.1 200 OK
                                     Content-length: 153
                                     Content-type: image/png
                                     Assoc-Req: a69add09
                       <-------

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.

Regards,
Willy

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 12 Sep 2010 01:20:58 +0200

> 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