W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

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

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Wed, 11 Aug 2010 14:56:51 +0800
To: Willy Tarreau <w@1wt.eu>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <8B0A9FCBB9832F43971E38010638454F03ED35A5A2@SISPE7MB1.commscope.com>
> 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.

Received on Wednesday, 11 August 2010 06:56:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:48 UTC