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