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

On Wed, Aug 11, 2010 at 09:27:28AM +0800, Thomson, Martin wrote:
> Hi Willy,
> 
> To me, hinting is the most important part.  You need to know that a) the server and intermediaries that you are traversing wont break, and b) that there are no other problems with specific resources, like potential head-of-line blocking.
> 
> As for the request ID, I think that Mark's succinct description works best:
> 
> "
> For example, if client A makes a request to a proxy cache with:
>   Req-ID: abc
> and the proxy goes to the origin server and gets a response with:
>   Req-ID: abc
>   Cache-Control: max-age=300
> ...and then client B makes a request to the proxy cache with:
>   Req-ID: def
> and gets the same response back from the cache (remembering that it hasn't been modified to support this), it'll get an error.
> "

That's precisely why I was suggesting that the header should be marked
in Connection.

> If you go to the trouble of fixing the proxy to support pipelining (again, most do), then all you really need is some indication that it's safe to proceed, not a per-request header.

I see your point, but given the multiple possible paths to reach a same
point and the complexity involved by pipelining, seeing it succeed once
does not mean it will succeed twice even for the same site.

Ideally we could make use of OPTIONS requests as a first check that the
local proxy seems to support it. But that's very limited.

> The big challenge is with bad intermediaries and your plan seems to require that intermediaries change.  The bad ones wont.

I agree the bad ones won't change but at least the client gets an
indication that they don't work, exactly as with the Assoc-Req header.
In fact in my opinion it becomes a way for an intermediary to explicitly
declare support for pipelining. The currently broken ones won't announce
it, that's fine, let's not pipeline with them.

Regards,
Willy

Received on Wednesday, 11 August 2010 05:02:41 UTC