DUI.Stream and HTTP request pipelining

Today I read about DUI.Stream:

We call this technique MXHR (short for Multipart XMLHttpRequests), and we wrote an addition to our Digg User Interface library called DUI.Stream to implement it. Specifically, DUI.Stream opens and reads multipart HTTP responses piece-by-piece through an XHR, passing each chunk to a JavaScript handler as it loads.

But how is that fundamentally different from HTTP request pipelining, where an HTTP client sends a stream of HTTP requests without waiting for a response before issuing the next request? HTTP request pipelining was standardised in RFC2616 - HTTP/1.1 .

Well, one major difference is that Digg can allow all their users to take advantage of their technique today. Amazingly, HTTP request pipelining is still disabled by default in the current releases of Firefox. On the IE side, it has been enabled in IE 8.

I notice that the 10th birthday of RFC2616 is coming up in June. I wonder if we should all mark the occasion by enabling HTTP request pipelining, by upgrading our browsers, or by going to about:config and tweaking it manually.

Comment from Anonymous

because pipelining does cause major screw ups .. see Mark Nottingham's talk at QCon .. on infoq.com

Comment from David Wragg

Hi Anonymous,

Until Google learns to index video, I find watching technical talks to be a very inefficient way to consume technical content. So I'm afraid I won't be watching Mark's talk, despite following his blog for a number of years.

All of the criticisms of pipelining I have found online amount to quality-of-implementation issues in certain HTTP servers and proxies. This is the rationale for Firefox not enabling the feature. Yet this leads to a chicken-and-egg situation: Sites have buggy HTTP infrastructure because few client exercise it, and vice versa. Perhaps this will change now that IE8 has enabled the feature. If so, it will be a novelty to see IE lead a standards-advocacy effort, with FF following.

Comment from anentropic

Isn't the difference that in MXHR the client makes only one request and receives a single response, with multiple parts.

Seems quite different from making multiple requests in sequence and receiving multiple responses.

For the particular use-case of Ajax where you have a client perhaps submitting a form and receiving back a mix of json data, html etc the MXHR way seems more efficient even?