Monday, April 3rd, 2006

Reusing XMLHttpRequest Without abort()

Category: IE, JavaScript, Programming, XmlHttpRequest

Last week, we mentioned Eric Pascarello’s “XMLHttpRequest Reuse Dilemma” article. Eric explained that to reuse an XMLHttpRequest object in IE, you must call abort().

In a follow-up, Pavan Keely says you actually don’t need the abort() call. Instead, just make sure the open() call happens before onreadystatechange(), rather than afterwards (as in Eric’s example).

The code developed in the article uses the javascript statements

req_fail_IE.onreadystatechange = processReqChange_fail_IE;
req_fail_IE.open(“GET”, url, true);
req_fail_IE.send(“”);

where it assigns the callback handler to the XMLHttpRequest, open the request and send the request which actually transmits the request.

Instead of this piece of code, just try using the following code and it will do the trick. Believe me and it’s worth trying.

req_fail_IE.open(“GET”, url, true);
req_fail_IE.onreadystatechange = processReqChange_fail_IE; //changed the position of callback handler
req_fail_IE.send(“”);

So even with IE, we can avoid the abort() call. However, what if the call is already in progress? If we’re going to start a new request, shouldn’t we call abort() to ensure nothing weird happens when the original response arrives. Pavan says there’s no need.

No, I wouldn’t want to. Because browser is intelligent enough to see whether to proceed with the request furthur or not when I issue one more call on the same XHR object. If one request is being processed on one instance of XHR object and if the application issues one more call on the same XHR, browser will abort the first request and proceeds with the second request. This is not just theoritical analysis but I did few testings too in IE6 which favor my analysis.

Another question about this, raised by Eric in a followup post is memory implications. Would an abort() call prevent memory leakage?

Important stuff, and exactly the kind of thing most programmers shouldn’t have to real with directly! All this is another reason to reuse a suitable remoting library unless you have a really good justification for rolling your own.

Posted by Michael Mahemoff at 3:03 pm
3 Comments

+++--
3.7 rating from 50 votes

3 Comments »

Comments feed TrackBack URI

We’ve done quite a bit of testing to remove leakage in Dojo, and the problem w/ XMLHTTP request objects (on IE anyway) always revolved around how the event handlers are set. The number of XMLHTTP objects created had little to no bearing on the leakage characteristics of the page.

The only thing that actually reduced leakage was handling state changes with a timer-based observer vs. directly attaching readystate handlers.

It’s frustrating to see these “what if!?!” kinds of things get repeatedly posted when we’ve already done the research and found solutions.

Comment by Alex Russell — April 3, 2006

When I do XHR.abort() while XHR.readyState is 4, from within the onreadystate function, the XHR object gets “stuck” in readyState 4 and also runs the onreadystatechange function over and over again (with readyState=4).

Comment by Adi Zholkover — August 5, 2006

We have another wierd issue when we try to abort a XHR before its complete, i.e when we close the window before the request comes back. After two times that we close the window, the XHR simply doesnt seem to respond. We need to shut down all the instances of IE to overcome this. Has anyone faced this before?

Comment by Sri — September 29, 2006

Leave a comment

You must be logged in to post a comment.