- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 19 Feb 2008 10:50:36 -0800
- To: Kris Zyp <kzyp@sitepen.com>
- Cc: Mark Baker <distobj@acm.org>, public-webapi@w3.org
Kris & Mark, My latest information about the problems with enabling HTTP pipelining is about five years old, so it will take me time to do research and provide more detailed information. That being said, the last time we experimentally enabled HTTP pipelining in internal Safari builds, we found the following: 1) Some web servers on the public Web had problems with pipelining. 2) Some proxy servers had problems with pipelining. 3) In at least some cases, these problems took the form of scrambling together multiple replies in a way the HTTP library could not reliably detect. The upshot of #3 is that we couldn't even turn on pipelining and back off if it failed. We would not be able to tell it failed in all cases; the result would be silent user data corruption. We decided that even though it would happen to a minority of users, it was not worth the risk for a potential performance optimization. The upshot of #2 was that there wasn't even a good way to provide a whitelist of sites where it was known to work, since we could not predict what proxy a user would be running. It may be that these problems are no longer common. However, I don't think our position should be to assume there is no problem until proven. Instead we should together try to investigate the current state of these issues. I will do my best to find whatever information I can. With this in mind, some specific replies to some of your comments: On Feb 18, 2008, at 8:28 PM, Kris Zyp wrote: >> Since the breakage is caused in at least some cases by proxies, it >> is not in general safe to let XHR users opt in since they may >> control the origin server but generally would not control whatever >> proxies are between the server and the user. >> >> Pipelining is a great potential performance improvement and it's >> sad that it can't safely be used on the public Internet right now, >> so I hope we someday find a way out of the impasse. > > There is a world of difference between browsers choosing to do > pipelining where no one gets to opt-in, and XHR opt-in where > developers know the origin server, may even know the full route for > all users (as in intranets) and can make the calculating risk of > where they want to try pipelining or not, and can even code backup > solutions when pipelined requests fail. I disagree that there is a world of difference. Since many of the problems are with proxies, it still be unsafe to use pipelining on a public site when specially requested. > It seems very presumptious to tell developers that can't take that > risk. Why not tell them they can't use XHR at all, since there are > old browsers out there don't support XHR? Because developers should > be given the opportunity to make this decision. Developers have > chosen to use XHR even though there are browsers that don't support > it, and this has led to progress. If they experience too much > pipelining failure they can choose to opt-out. I am very skeptical > that at this point the failure rate is high enough that very many > developers would opt-out. The nature of the risks that some browsers don't support XMLHttpRequest, and that some configurations may result in problems with pipelining, are not the same. When content runs on one of the rare clients that does not support XHR, it can detect that fact up-front on the client side, and provide an error message or some form of graceful fallback. Even if it does not check and attempts to use XHR blindly, the negative consequence will be that the operation completely fails in an obvious way. However, when content requests HTTP pipelining in a configuration where it will fail, it cannot detect the failure up front or even after the fact. The result of proceeding in the face of failure will not be a clear failure but rather data corruption. While less than 1% of users may experience these kinds of problems, an API that may expose even a small proportion of users to unpredictable data corruption is not a good idea. In particular, browsers that implement the ability to request pipelining will expose users to these problems, while older browsers will not, so the likelihood is high that the browser will be blamed. I would ask further why HTTP pipelining is especially more important for XHR than for normal fetching of HTTP resources. Fundamentally, it is nothing more than a performance optimization, and even the most AJAXey of sites makes many more ordinary resource requests than XHR requests. > Ironically, this is probably our best opportunity to get through > this impasse. If web developers can selectively turn on XHR, the few > remaining proxies out there that break under pipelining will start > to be singled out, and more likely to be fixed which in turn will > create the pipeline reliability for browsers to use it more broadly. I think there is a better way to break the impasse. (See end of this message). On Feb 18, 2008, at 9:20 PM, Mark Baker wrote: > Hi Maciej, > > On 2/18/08, Maciej Stachowiak <mjs@apple.com> wrote: >> Last time I looked into this, there were some proxies and some origin >> server configurations (in particular certain Apache modules, perhaps >> now obsolete) that broke with pipelining. > > Can you define "broke"? > > I've done a search on Apache and Squid pipelining bugs, and didn't > find any open ones. I'll try to do more thorough research, but see above. The result was undetectable data corruption in at least some cases. >> Since it is not possible to >> find out from the server if pipelining is correctly supported, and >> since it is not generally possible to tell from the response that it >> has failed, enabling it by default in the browser http stack was >> not a >> safe thing to do. >> >> Since the breakage is caused in at least some cases by proxies, it is >> not in general safe to let XHR users opt in since they may control >> the >> origin server but generally would not control whatever proxies are >> between the server and the user. >> >> Pipelining is a great potential performance improvement and it's sad >> that it can't safely be used on the public Internet right now, so I >> hope we someday find a way out of the impasse. > > Well, I'd like to see some hard evidence of this before we write it > off. I think we need some research before making a decision either way. I just wanted to make clear the nature of the risks, and in particular that content author opt-in was not sufficient to fully mitigate them. In any case, I think there is a safer way to enable safe opt-in to HTTP pipelining, not just for XHR but for all content. I think the best solution is to us a hop-by-hop HTTP header to signal server-side support for pipelining. In particular, the "Connection" header is hop- by-hop, allows an open-ended series of values, and is semantically appropriate for this purpose. So I would propose that we define an HTTP response header field of "Connection: pipeline" to indicate that the server supports pipelining and encourages its use for this particular connection. I believe this solution is better than a script-side solution in two ways: 1) The opt-in uses a hop-by-hop mechanism, so it will not cause problems with proxies when the origin server can promise to correctly implement pipelining but an intervening proxy cannot. Therefore it will save us the effort of even investigating the potential problems caused by troublesome proxies and weighing their cost. 2) It can work for ordinary resource loads as well as for XHR, so the potential performance benefit is much greater. Probably the appropriate forum to make this proposal would be the IETF HTTP Working Group. I'll join the appropriate mailing list if others are interested in pursuing it there. In advance of this, we could agree by convention on an unofficial "Connection: x-pipeline" value to see how well this proposal works in practice. Thoughts? Regards, Maciej
Received on Tuesday, 19 February 2008 18:50:57 UTC