Re: multipart, server-sent events, and

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