IE8’s Native XMLHttpRequest Object Restrictions, Bugs, and Notes

Protocol Restriction
Internet 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 Restriction
The 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 Restriction
IE7'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 behavior
The 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 Bug
IE'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 notes
There's some more documentation comparing and contrasting the native object and the legacy MSXML ActiveX Control over on MSDN.

Comments (11)
  1. FremyCompany says:

    Hihi, the only reason I ever wanted to use…, false), that was to perform a CPU-free sleep() function. I did it until I noticed the browser was frozen during the sleep time…

    Maybe you should consider avoiding that a JavaScript freeze the whole browser, and even a simple page. I don’t notice such behaviour on Chrome, for example. It seems that the JScript is executed on another thread than the render engine. A good thing.

    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 :

  2. @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.

  3. chrisbro says:

    Actually, our app just switched to passing in synchronous during shutdown to fix the 401-during-OnNavigate bug we were talking about…

  4. EricLaw [MSFT] says:

    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. 🙂

  5. Gyll says:

    The restriction of XMLHttpRequest on allowing the file:// protocol is difficult. I can’t debug an application locally in IE.

  6. Thorin Linderholm says:

    Re: Overaggressive Caching bug

    In my testing IE8’s XMLHttpRequest implementation incorrectly caches responses that have the ‘Cache-Control: no-cache’ http header if it got there via a 302.  (in other words, if it request, for example and that page returns a 302 to, if you ever do a subsequent request to that response with the same 302, XMLHttpRequest will NOT EVER actually make the request to after the first time, despite the fact that both the 302 response and the response to both set ‘Cache-Control: no-cache’

    I don’t know why it would do this, but it certainly seems to violate the http specification, and it’s very annoying, not to mention potentially a huge security problem, assuming there is a good reason for the Cache-Control: no-cache header.

  7. ieblog says:

    @Thorin: Where’s your test page, please?

  8. Thorin Linderholm says:

    This is in the middle of a large application right now, I don’t think I’ll have time to set up a public test page.

    Doing a 302 at all is really a legacy thing I can probably remove, and which will be much faster than waiting for a fix to IE8, assuming I’ve identified the exact minimal test case even.  There’s a document.write(…) of the response that could be confusing things, though I don’t believe so.

  9. Luis Osorio says:

    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.

  10. EricLaw [MSFT] says:

    <<neither XMLHTTPRequest nor the legacy MSXML pass ahead the Accept-Encoding headers >>

    No, that’s not correct.

Comments are closed.

Skip to main content