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 <[EMAIL PROTECTED]> 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
