- From: Jeffrey Mogul <Jeff.Mogul@hp.com>
- Date: Thu, 19 Jul 2007 10:45:19 -0700
- 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
http://www.watersprings.org/pub/id/draft-mogul-http-ooo-00.txt
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.
-Jeff
Received on Thursday, 19 July 2007 17:46:17 UTC