Please read my blog's comment policy here.
Protocol RestrictionInternet Explorer's native XMLHTTPRequest object permits requests to HTTP and HTTPS only; requests to FILE, FTP, or other URI schemes are blocked. Update: IE10 XHR supports CORS.
Method RestrictionThe object permits only the following HTTP methods: "GET", "POST", "HEAD", "PUT", "DELETE", "MOVE", "PROPFIND", "PROPPATCH", "MKCOL", "COPY", "LOCK", "UNLOCK", "OPTIONS". Update: IE9's XHR allows all methods except TRACK and TRACE.
Port RestrictionIE7's version of the object allows only requests to the same port; IE8's object removes that restriction. Internet Explorer does not consider the port to be a part of the Security Identifier (origin) used for Same-Origin-Policy enforcement, a quirk which will be the subject of some future blog post.
Aggressive Caching behaviorThe WinINET cache may reuse the response to a GET request if the server does not send any headers prohibiting caching, even if a query string is present. RFC2616 suggests that GET requests where the URL contains a query string should not be cached by default. Update: This isn't a bug per-se.
Workarounds: Either use the POST method, a randomly-generated-per-request query string, or (best) configure the server to send proper cache directives.
HTTP/204 BugIE's XMLHTTPRequest object incorrectly returns a status code of 1223 and drops all headers if the server returns a "HTTP/204 - No Content" response. Update: Fixed in IE10.
Synchronous Mode = "Hang me, please"Developers should never pass false for the bAsync parameter, as this can (and often does) result in browser hangs in the event of network slowness.
Other notesThere's some more documentation comparing and contrasting the native object and the legacy MSXML ActiveX Control over on MSDN.
Hihi, the only reason I ever wanted to use xhr.open(..., false), that was to perform a CPU-free sleep() function. I did it until I noticed the browser was frozen during the sleep time...
Another IE's quirks you don't speak about here is the Memory Leak when you mix up DOMNodes and XHR objects. It has been mitigated in IE7, and a bit more in IE8, but it's still present in some cases, if I've good understood what I've read : http://j15r.com/example/spew.html
@FremyCompany: Threading is a very tricky thing. You cannot simply take something which is synchronous and make it effectively asynchronous by putting it on another thread, for instance. You could try to decouple the UI thread from the "main" thread such that the blocking XHR doesn't block UI, only everything else, but there's quite a lot of work to be done there. In all environments, using the synchronous pattern for network calls is simply a bad idea.
In terms of memory leaks, this simply isn't an area I'm an expert in, but it's worth mentioning that IE8 has a significantly advanced GC which is far better at finding objects to clean up. (It's actually so aggressive that in RC1 we had to take some fixes to prevent it from GC'ing technically collectable image objects, because pages rely on images being downloaded even if unreferenced). In order to say that there's actually a memory leak, we'd need to have a reduced repro case to eliminate web dev error as a culprit.
There's a neat test page for response codes/text here: http://www.monsur.com/httpstatuscodes/test.html
Referenced by: http://monsur.com/blog/2007/12/28/xmlhttprequest-status-codes/
Actually, our app just switched to passing in synchronous during shutdown to fix the 401-during-OnNavigate bug we were talking about...
Chris is referring to the problem that if you use an async XHR to make a call during OnUnload, if the server returns a HTTP/401 to demand authentication, IE will not respond to that 401 authentication challenge. In contrast, if you use a synchronous XHR request, IE does appear to reissue the request with credentials before tearing down the page.
Overall, Chris is trading functionality against slower tab shutdown, and the possibility that IE will appear to hang. That's precisely the sort of decision that drives us on the IE team crazy. :-)
The restriction of XMLHttpRequest on allowing the file:// protocol is difficult. I can't debug an application locally in IE.
Other very important thing to notice.
If you have Apache + PHP with HTTP compression enabled. As you may know Iexplore deals with compressed contents only when it sends the 'Accept-Encoding' header with the request, if try this in Iexplore neither XMLHTTPRequest nor the legacy MSXML pass ahead the Accept-Encoding headers so the web server sends the compressed content but firefox will work as expected... I tested disabling the antivirus software on both client and server, I am not behind a proxy, the web server resides in my same subnet, the request is not passing any firewalls and Iexplore continues receiving uncompressed content even setting the explicit headers along with the request.
I was in the process of developing a RIA and had to cancel the project due to this bug in the implementation of XMLHTTP Request and go back to continue using MS Access.
In conclussion, if you are dealing with large datasets, please stay with your current desktop applications and never go RIA.
<<neither XMLHTTPRequest nor the legacy MSXML pass ahead the Accept-Encoding headers >>
No, that's not correct.