Re: multipart, server-sent events, and

> state of these issues. I will do my best to find whatever information  I 
> can.
I appreciate that, I will try to research it as well. Five years is a long 
time in on the web, a lot could have changed.
Some evidence I have turned up with a little research:
Opera supports pipelining by default. Firefox allows users to enable 
pipelining and according to Robert, it will be enabled by default. This 
indicates that pipelining has been tested by browsers in the wild, it is not 
without some validity. They both use heuristics to determine if pipelining 
is appropriate. This most notable heuristic is disabling pipelining for IIS 
servers, which is another case where origin server knowledge properly 
facilitates informed consent.

> 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
Once again, why not let authors make this decision? There are other browser 
quirks that lead to unpredicable results. If developers think <%1 is worth 
risk, they should be able to do that. There may be clever ways to work 
around these issues that we haven't even thought of yet. And once again some 
developers are developing for intranets where the routes are controlled. Why 
penalize them due to uncertainties on the open internet?
XMLHttpRequest is much different than having some menu option to enable 
pipelining. Many web developers use frameworks that wrap XHR, but those that 
actually directly interact with XHR are usually doing so because they want 
precise control of their requests. Why not let them have it? They can read 
the literature on how dangerous it is and choose if it is worth it. The fact 
that Opera and now Firefox are doing so broadly certainly would suggest that 
it is a valid enough choice that devs could at least opt-in.

> 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.
I am not opposed to pipelining of all resources, but XHR provides an API for 
opt-in, so devs can explicitly choose to pipeline. Second, sometimes 
pipelining can actually be detrimental, if a slow resource ends up having 
several requests that become queued behind it. With explicit pipelining, 
developers can have control and ensure the correct delegation of pipeline 
requests for optimum efficiency. Finally, in particular with "comet-style" 
long-lived responses, being able to control pipelining is even more 
important. One can pipeline requests over the long-lived response connection 
to create a duplex communication over a single TCP connection. One can 
pipeline requests to another connection to ensure that responses are 
received properly. There is simply no way to do this efficiently otherwise, 
and comet-style communication requires two connections for duplex 
conversation even though it is fully with the means of HTTP do it over a 
single connection.


> 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.
Freedom is not intended to be a risk mitigation. Opt-in is a choice to 
accept risk, not mitigate it.
> 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 don't think this is a bad idea. But for the reasons stated above, I still 
think it is important to have an XHR API to suggest pipelining.
Thanks for your feedback.
Kris

Received on Tuesday, 19 February 2008 19:40:21 UTC