Wednesday, October 17th, 2007
Re-inventing XMLHttpRequest: Cross-browser implementation with sniffing capabilities
Category: Ajax
, JavaScript, Library
Sergey Ilinsky has written up an article on an XMLHttpRequest implementation wrapper that provides an equal XHR playground across the various browsers.
If you use the wrapper you can fix things like:
- Internet Explorer: memory leak in XMLHttpRequest
- Gecko: missing readystatechange calls in synchronous requests
- Gecko: unnecessary readystatechange DONE when request aborted
- Gecko: Annoying <parsererror…>…</parsererror> documents
- Internet Explorer + Gecko: duplicate readystatechange OPEN triggered
As part of his work Sergey compared the browser implementations:
And has made his code available for download.
3.1 rating from 48 votes
Great job. What I’ve found most exciting about your implementation
was actually sniffing - pity there have been no attention given to it in the review.
Nice! Now is it possible to get JQuery (for example), or other framework use it easily?
I don’t know if something would break if I just include this script before any framework.
Zsolt,
It should not be a problem using XMLHttpRequest implementation with any frameworks. We at Backbase use it in our client-side debugger enabling the I/O inspector.
Just had a look at the code and noticed that it’s only testing for the Microsoft.XMLHTTP progid… I know that that particular namespace/progid is bound to v1 - v3 of MSXML. What I don’t know/understand is why most/all of the Ajax frameworks test for this progid and sometimes others e.g.
(YUI) _msxml_progid:['MSXML2.XMLHTTP.3.0', 'MSXML2.XMLHTTP', 'Microsoft.XMLHTTP'] - (if yui is only supporting IE6+) all these progids will point to the same version, so the test is a waste of time…?
dojo.hostenv._XMLHTTP_PROGIDS = ["Msxml2.XMLHTTP", "Microsoft.XMLHTTP", "Msxml2.XMLHTTP.4.0"];
These progids suggest they support IE4x and IE5x… ?
I know that IE6 comes with MSXML3 and Microsoft recommend only using MSXML3 (or MSXML6 - which comes with Vista) progids.
Surely if they’re supporting IE6+ then the correct progid is MSXML2.XMLHTTP.3.0 to quote the Microsoft blog…
Try MSXML6 and fallback to MSXML3 – MSXML6 has some improvements that aren’t in MSXML3 such as support for XSD schema, and improved stability, performance, and security. So your app may try out MSXML6 if it is on the box and then “fallback†gracefully. Just remember to test your app with MSXML6 and with MSXML3 so you aren’t surprised when you release your application.
Is there something I’m missing? Are there known bugs with the specific versions of MSXML that these frameworks work-around? What happens if M$ drop support for the “Microsoft” namespace?
Cheers,
Confused.
Dave,
I think your concerns are very valid. Still I found only one looking serious: “What happens if M$ drop support for the “Microsoft†namespace?” Well, as you saw in the source, this will not be a problem, since in the environments where M$ might consider dropping this support there is already XMLHttpRequest object available - and my implementation will wrap around that one, not trying to locate an existing ActiveX!
Nice article.
Will tryout wid dojo.
Java
Interesting, if nothing else nice just to get cross-browser stats.
Bra jobbat :)
There is a specific issue with microsoft’s early implementation of MSXML (an ActiveX) - some organizations have such strict security so they totally disable ActiveX in IE, but still IE is the default and only browser. There is a workaround in IE 5-6 by using XML data islands, which in turn internally use the same ActiveX object, but somehow that is not affected by the security settings of whether to use or not to use AX.
What is most intriguing is that in NONE of the major frameworks I have not seen an implementation that uses as a fallback the XML data islands.
Haven’t the creators of those libs never met this issue, or they think that one way or the other “AJAX” will prevail and they are not concerned by what some government IT agency example enforces as a quite reasonable security policy?