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

Re: Suggestion for NEW Issue: Pipelining problems

From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Thu, 19 Jul 2007 10:45:19 -0700
Message-Id: <200707191745.l6JHjJ2S014114@pobox-pa.hpl.hp.com>
To: Jamie Lokier <jamie@shareable.org>
cc: yngve@opera.com, HTTP Working Group <ietf-http-wg@w3.org>

    Given that it's not so easy to deploy, and the silly requirement of
    client guesswork even with good servers, I wonder if it would be
    better to simply deprecate pipelining, and instead develop a reliably
    advertised and broken-proxy-safe flavour of out of order multiplexing.
This is obviously out-of-scope for the RFC2616-bis effort, but
it might be worth exploring a way to support out-of-order responses.

In fact, I did that, about 6 years ago: see


which proposed a "simple, compatible, and optional extension to HTTP to
allow a server to issue responses out of order".  Note that I chose
to make this a hop-by-hop design; the I-D explains the rationale.
Using the "Connection" header thus satisfies (I think) your desire
to make this "reliably advertised."  That I-D died at the time,
for lack of interest, but I have no objections if someone wants
to try again.

While I share your desire to make this "broken-proxy-safe",
I think that's probably impossible.  The I-D has a detailed
section on what could go wrong.  I think if we tried to insist
on all HTTP features being "broken-proxy-safe", we would
be unable to make any progress.

What I don't understand is why you think that support for
out-of-order responses would motivate us to drop support
for (deprecate) pipelining.  I would think that O-O-O support
would make pipelining even more useful, and vice versa.
Or more precisely, I don't see how it makes sense to reorder
responses unless the requests are pipelined.

Received on Thursday, 19 July 2007 17:46:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC