Tuesday, January 12th, 2010
Progressive XMLHttpRequest
Category: Ajax
Perhaps it's subtle, but the draft spec for XMLHttpRequest calls for support for progressive response handling:
4.7.6 The responseText attribute The responseText attribute must return the result of running these steps: 1. If the state is not LOADING or DONE return the empty string and terminate these steps. 2. Return the text response entity body.
He then goes on to test this out by having a response with delimiters such as:
JAVASCRIPT:
-
-
window.aFunction();
-
// -- //
-
window.bFunction();
-
// -- //
-
and then watching for those in the response:
JAVASCRIPT:
-
-
var index = 0;
-
var buffer = '';
-
var DELIMITER = '//--//';
-
-
function handlePartialResponse(request) {
-
var i = request.responseText.lastIndexOf(DELIMITER);
-
if (i> index) {
-
i += DELIMITER.length;
-
var newChunk = request.responseText.substr(index, (i - index));
-
buffer += newChunk;
-
index = i;
-
flushBuffer();
-
}
-
}
-
Related Content:
4 rating from 22 votes
This is a great approach. I used a similar appoach in a reverse ajax framework I wrote (http://www.thecodingmachine.com/ext/xaja/doc/).
I believe frameworks like Orbited or Meteord use similar techniques too.
The problem of course, is that this technique does not work in IE… so I have to go back to dreadful techniques, like the “htmlfile” activex, pretty well described by Michael Carter here:
http://cometdaily.com/2007/11/18/ie-activexhtmlfile-transport-part-ii/
Hopefully, websockets will help us sort this mess out in an elegant way.
Why would they not just use multipart/mixed? It’s been around forever and does exactly the same thing as progressive XHR handling.
Hell, I’ve already written an implementation to handle multipart responses through xhrs called MXHR. I’m pretty sure you guys blogged about it last year when it was first released: http://github.com/digg/stream
Long story short: XHRs already support reading chunks as they come in, and if you’re going to parse multipart boundaries yourself, you may as well conform to the MIME spec.
Very simple (and therefore very nice) – though I think IE still barfs if you try to access the response when ready status === 3
Several of IE’s XHR implementations already support access to responseText when readyState is still 3. I poked around all of the different version and listed them in DUI.Stream.
I was waiting to see how the discussion develops (it didn’t). What Micah’s saying makes sense. Please – don’t reinvent the wheel. Using MIME multipart makes sense to me. For DUI.Stream if you want to make changes.
It seems to me that DUI Stream has a very specific purpose: aggregate several external resources into a single response. For this purpose, the semantics of multipart/mixed are appropriate, since each “part” represents a distinct resource. I think that’s an interesting application.
Regarding IE XHRs supporting access to responseText at readyState == 3, I’d love to see a simple example of this working, but all of my test cases fail. I’m happy to post them if you’re interested.
True, I guess multipart/related would make more sense for sending several JS chunks.
Line 52 of Stream.js has the versions of XHR that I found to work in IE (the original idea for testing different implementations was Jordan Alperin’s): http://github.com/digg/stream/blob/master/js/Stream.js#L52
Below that I left comments with the ones I tested that don’t support readyState == 3.