- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 11 Aug 2010 07:08:41 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Thomson, Martin" <Martin.Thomson@andrew.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Aug 11, 2010 at 02:07:48PM +1000, Mark Nottingham wrote: > Exactly. > > The properties that I'm looking for are ones that will make it safe from a browser vendor's perspective; i.e., they can deploy pipelining and not break existing sites (which they inevitably get blamed for). > > By making pipelining effectively opt-in through hinting, the decision is in the hands of the server administrator, not the browser. It's not an optimal situation, but it does give us the opportunity to realistically make the world better. Expecting intermediaries to suddenly get better is IME not realistic. That's not what I was saying, Mark. Instead it goes exactly in the direction you suggest above. By hinting the browser knows it can use pipelining, so that new browsers can ship with pipelining enabled by default. Then, pipelining will have to be enabled on the server sides in order to be usable. And from the browser's perspective, "the server" means the local proxy, as all intermediaries, as well as the origin server. I'm not expecting the intermediaries to suddenly get better, and even I think that many of them won't improve, but the mechanism at least makes it clear which ones have explicit support for pipelining and which ones don't. Once again, my goal is that browsers can ship with pipelining enabled by default. Even if today there are a few intermediaries that already support pipelining well, not making use of their ability until they're upgraded will not be a big waste, considering the extremely low deployment rate of pipelining today. Regards, Willy
Received on Wednesday, 11 August 2010 05:09:12 UTC