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

Re: Suggestion for NEW Issue: Pipelining problems

From: Jamie Lokier <jamie@shareable.org>
Date: Wed, 18 Jul 2007 11:06:25 +0100
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: yngve@opera.com, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20070718100625.GC19800@mail.shareable.org>

Roy T. Fielding wrote:
> >The question is if something can be done with the existing system,  
> >for example by adding some headers, or should a new system be created?
> 
> No.  The same broken implementations will just break the new system,
> and then we have twice as many broken ways to do the same thing.
> 
> The solution is trivial.  When you encounter a broken server, display
> an error message (not a stupid modal dialog that stops everything and
> prevents further progress until a user presses the OK button, just a
> side box that indicates the server is broken because ...).  Convince
> the other major browser developers to do the same and all of those
> problems will quickly disappear on their own.

I don't think "major browsers" will be keen to appear broken to their
users, for the sake of a minor potential performance tweak.  If a site
works fine on other browsers, and has worked fine for years on all of
them, to a user it's the new browser which is broken.

However, a "This site has a faulty HTTP implementation" advisory which
can expand to more detail, like those warning bars which sometime
appear at the top of a page in Firefox, would allow sites to continue
to be used, while motivating developers to remove the unsightly warning.

That said, pipelining is quite a poor way to improve performance, and
even correct implementations need guesswork on the client side, to
guess whether a response will block subsequent responses.

Out of order multiplexing would be _much_ better.

I suspect pipelining was added to HTTP because it's such a trivial and
natural change - in fact no change to many servers - that it was
thought it might be easy to deploy.  And there is no excuse really for
getting it wrong, it really is quite trivial to implement.

But in practice, it's not being deployed much on the internet because
of it's unreliability with some servers and proxies - and worse,
there's no way (at the HTTP level) to detect when it goes wrong.

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.

-- Jamie
Received on Wednesday, 18 July 2007 10:06:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT