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

On Wed, Aug 11, 2010 at 02:56:51PM +0800, Thomson, Martin wrote:
> > 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.
> 
> The only sort of indication that a client is likely to get for a bad proxy/server is the absence of any mechanism that is defined.
> 
> So, if all we are looking to achieve is to indicate that the proxy (read: next hop) expressly supports pipelining, all you need to do is add a header:
> 
>   GET http://example.com/foo HTTP/1.1
>   Pipeline: yes          <-- read: please
>   Connection: pipeline
>   ...
> 
>   HTTP/1.1 200 OK
>   Pipeline: yes          <-- read: OK
>   Connection: pipeline
> 
> (Actually, you don't need the Pipeline header, just the connection token - the header contains no extra information.)
> 
> Subsequent requests to that host can omit the token - you already know that pipelining is safe.
> 
> That does the same as what you proposed with less mechanism.  It doesn't address the bad intermediary problem, but it helps a client identify if pipelining is safe to attempt.

I completely agree with you, Martin. My point was to try to automatically
eliminate bad intermediaries (as what the original proposal does), but
your proposal is much cleaner though it also relies on updates in
intermediaries (as did mine).

After all, it's how the support for keep-alive was added. And the
advantage is that it remains a connection oriented check and as you
pointed, can be omitted in subsequent requests as the connection's
status won't change.

Regards,
Willy

Received on Wednesday, 11 August 2010 07:08:07 UTC