Re: Suggestion for NEW Issue: Pipelining problems

Jeffrey Mogul wrote:
> 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.

At least, we should enumerate the known problems with deployed proxies
- visible and hidden ones - and the extent of the problem, so the
implementors can decide whether to implement particular features, or
if the problems outweigh the benefits for them.

I suspect we can make more advanced HTTP broken-proxy-safe but only by
running it through an overlay network which looks like HTTP/1.0
messages to old proxies.  Something to wait a few more years before
standardising, I think.  (There are implementations already, running
over the internet).

Perhaps the problem of HTTP proxies intercepting traffic, or being the
only available connectivity, will be less prevalent in a few years anyway.

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

I was suggesting deprecating pipelining-in-order as it is described in
RFC2616, because of the problems clients have of guessing when it's
safe, and when it isn't, due to the responses blocking other
responses.

Of course, overlapping requests is essential for performance, and I
was suggesting that in-order pipelining be deprecated, while replacing
it with a mechanism for pipelined requests with out-of-order responses
- the same as you have in mind.

For a private application I'm working on, which uses a protocol like
HTTP but not quite the same, I do something like that and it works well.

-- Jamie

Received on Friday, 27 July 2007 12:15:16 UTC