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: Mark Nottingham <mnot@mnot.net>
Date: Wed, 8 Sep 2010 10:34:42 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <F8785118-4CC5-4315-AB1B-3FFFA893D524@mnot.net>
To: Patrick McManus <mcmanus@ducksong.com>

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/
Received on Wednesday, 8 September 2010 00:35:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:25 GMT