Tuesday, January 12th, 2010

Progressive XMLHttpRequest

Category: Ajax

Kyle Scholz has brought up the topic of progressive response handling in XHR:

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:


  1. window.aFunction();
  2. // -- //
  3. window.bFunction();
  4. // -- //

and then watching for those in the response:


  1. var index = 0;
  2. var buffer = '';
  3. var DELIMITER = '//--//';
  5. function handlePartialResponse(request) {
  6.   var i = request.responseText.lastIndexOf(DELIMITER);
  7.   if (i > index) {
  8.     i += DELIMITER.length;
  9.     var newChunk = request.responseText.substr(index, (i - index));
  10.     buffer += newChunk;
  11.     index = i;
  12.     flushBuffer();
  13.   }
  14. }

Posted by Dion Almaer at 11:54 am

3.9 rating from 41 votes


Comments feed TrackBack URI

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:

Hopefully, websockets will help us sort this mess out in an elegant way.

Comment by DavidApideo — January 12, 2010

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.

Comment by Micah — January 12, 2010

Very simple (and therefore very nice) – though I think IE still barfs if you try to access the response when ready status === 3

Comment by AngusC — January 14, 2010

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.

Comment by Micah — January 15, 2010

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.

Comment by zzen — January 17, 2010

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.

Comment by kylescholz — January 17, 2010

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.

Comment by Micah — January 19, 2010

Leave a comment

You must be logged in to post a comment.