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

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

--Martin