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.