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

On 11/08/2010, at 6:53 PM, Willy Tarreau wrote:

> On Wed, Aug 11, 2010 at 05:29:32PM +1000, Mark Nottingham wrote:
>> It's interesting, but it would require browsers to spew Req-MD5 headers into requests unconditionally... something that I can't imagine they're likely to want to do (especially at first, when adoption on the server side is low).
> 
> Well, it's cheap and scalable. Also, it's hard to imagine that browsers
> will both want to have pipelining to work and do nothing for that.

That's a false choice; they don't mind doing something, but they do mind putting extra bytes on the wire for every HTTP request on the planet if it can be avoided.

> The
> "connection: pipeline" method suggested by Martin looks perfect to me
> in this regards, but it does not address the point you want to address
> which is to try to detect bad intermediaries without having to upgrade
> them.

I think we're going to have to disagree, but I'd encourage you to look at this from the perspective of a browser vendor.

> 
>> OTOH just doing the MD5 in the response is potentially interesting,
> 
> if the server does the MD5 itself, we're back to the problem I emitted
> about reverse proxies having to do the job themselves if they rewrite
> requests. This will remain broken for a very long time, until those
> reverse-proxies know how to write the header. Also, the problem of which
> one has to do it depending on the request path still exists. In practice,
> a browser may receive 4-5 different values for a same response header
> because multiple pipiline-capable reverse-proxies will have put theirs.
> 
> That's why I really think that having the server report the information
> it got is nice. That way we can ensure that even in case of multiple
> actors, the reported values are the correct ones.

I'm not concerned about reverse proxy deployments because they're under the control of the server, and looking at implementations I'm familiar with (Squid, Traffic Server, various others), it's pretty trivial to add a configuration option to take charge of this header. 

> That said, for the long run, my preference still goes for the
> "Connection: pipeline" method, which would take longer to deploy but
> which is more in line with the real needs :-)

When I think "longer to deploy", I think about techniques like SPDY, because they'll be more rewarding, given the effort required. 

Cheers,

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

Received on Wednesday, 11 August 2010 09:17:15 UTC