Share via

About Native XMLHTTP

This topic describes the native implementation of Extensible Markup Language / Hypertext Transfer Protocol (XMLHTTP) in Windows Internet Explorer 7 and later.

  • What is XMLHTTP?
  • Charting the Changes
    • XMLHTTP in IE7 vs. IE6
    • ActiveX vs. XMLHTTP
  • Security: Cross-Domain and Zone Policy
  • Related topics

What is XMLHTTP?

XMLHTTP was first introduced as a Microsoft ActiveX control in Microsoft Internet Explorer 5. Over time, this object has been implemented by other browsing platforms and is the cornerstone of Web applications based on Asynchronous JavaScript and XML (AJAX) and Simple Object Access Protocol (SOAP). The XMLHTTP object enables the browser to send and receive asynchronous, out-of-band HTTP requests to the Web server, which responds with XML. The response can be manipulated with client-side script or transformed with Extensible Stylesheet Language Transformations (XSLT). XMLHTTP makes it possible to create responsive Web applications that do not have to refresh the entire page to display new data.

Charting the Changes

In Microsoft Internet Explorer 6 and earlier, XMLHTTP was implemented as an ActiveX object provided by Microsoft XML (MSXML). Beginning with Internet Explorer 7, XMLHTTP is also exposed as a native scripting object.

XMLHTTP in IE7 vs. IE6

The native implementation of the XMLHTTP object is designed with cross-browser compatibility in mind. With just a bit of script, it is easy to build a function that works with either version of Windows Internet Explorer, or any browser that supports XMLHTTP. See XMLHttpRequest for complete documentation and examples.

var xmlHttp = null;
if (window.XMLHttpRequest) {
  // If IE7, Mozilla, Safari, and so on: Use native object.
  xmlHttp = new XMLHttpRequest();
  if (window.ActiveXObject) {
     // ...otherwise, use the ActiveX control for IE5.x and IE6.
     xmlHttp = new ActiveXObject('MSXML2.XMLHTTP.3.0');

Internet Explorer 7 supports the legacy implementation of XMLHTTP in addition to the new native object, so pages currently using the ActiveX control do not have to be rewritten. However, it is more efficient to create a native scriptable object than to create an ActiveX object. This is especially beneficial to those AJAX applications that create a new XMLHTTP object for each request.

The native object also supports the use of expandos (custom properties), and properly recognizes the 'this' notation of JavaScript.

ActiveX vs. XMLHTTP

Users and organizations that choose to disallow ActiveX controls can still use XMLHTTP-based Web applications in Internet Explorer 7. However, native XMLHTTP support can be disabled from the Advanced settings tab of the Internet Options dialog box, as shown in the following screen shot.

Security settings on Internet Options dialog box

Clients can configure their own policy and simultaneously retain functionality across key AJAX scenarios. By default, the native implementation of XMLHTTP is enabled for all MSHTML hosts; however, individual host applications can choose to disable XMLHTTP with the FEATURE_XMLHTTP feature control key. An organization can use Group Policy to disable XMLHTTP for all users of its network.

If native XMLHTTP has been disabled, developers can override the XMLHttpRequest property of the window object with the MSXML-XMLHTTP control, unless ActiveX has also been disabled, as in the following example.

if (!window.XMLHttpRequest) {
    window.XMLHttpRequest = function() {
        try {
            return new ActiveXObject('MSXML2.XMLHTTP.3.0');
        catch (ex) {
            return null;

Security: Cross-Domain and Zone Policy

Before an XMLHTTP request is sent, the URL of the hosting page is compared to the URL in the open method to determine if the URLs are in the same domain. If not, the request is handled according to the policy of the security zone in which the request originates. The native XMLHTTP object uses logic inherited from MSXML-XMLHTTP to determine how to handle cross-domain data requests, based on the following rules:

  • Cross-domain requests are allowed within the same zone if the Internet Explorer security manager has allowed "Access data sources across domains" (URLACTION_CROSS_DOMAIN_DATA) either implicitly or by prompting the user.
  • If the request is from a more trusted security zone to a less trusted one, the security settings of the originating zone apply. (The security zones, in order of trust, are as follows: Local Machine, Trusted Sites, Local Intranet, Internet.)
  • All cross-domain requests to or within the Restricted Sites zone are disallowed, regardless of selected security zone policy.

Note   In Internet Explorer 7, the default settings for cross-domain data access are set to "deny" for all security zones. Site developers might want to allow cross-site domain access for the Trusted Sites zone, and then add sites to this zone to test software under development. However, this architecture is intended only as a temporary workaround, and is not recommended for fully developed software.

Because the MSXML-XMLHTTP component is used to determine the policy for cross-domain access across zones, a trusted site can access data from a site in the Intranet zone, while the reverse is always denied. Wherever "Query Policy" appears in the following table, the security manager is consulted for the appropriate action: to allow, to deny, or to prompt the user.

From / To Local Trusted Intranet Internet Restricted
Local Disallowed Query Policy Query Policy Query Policy Deny
Trusted Deny Query Policy Query Policy Query Policy Deny
Intranet Deny Deny Query Policy Query Policy Deny
Internet Deny Deny Deny Query Policy Deny
Restricted Deny Deny Deny Deny Deny


To further minimize file access threats, cross-port and mixed protocol script access is checked to prevent the user from displaying potentially harmful content from what appears to be a trusted site. The native implementation of XMLHTTP allows only HTTP, Secure Hypertext Transfer Protocol (HTTPS), and a subset of HTTP verbs in calls to In Internet Explorer 7, the XMLHTTP request can only specify URLs with the same port and protocol method as that from which the page is served. In Windows Internet Explorer 8 and later, that restriction has been removed. Internet Explorer does not consider the port to be a part of the Security Identifier (origin) used for Same Origin Policy enforcement.

Internet Explorer only permits the following HTTP methods: "GET", "POST", "HEAD", "PUT", "DELETE", "MOVE", "PROPFIND", "PROPPATCH", "MKCOL", "COPY", "LOCK", "UNLOCK", and "OPTIONS".

The following table compares the security implementation of native XMLHTTP with MSXML.

Feature Native XMLHTTP MSXML 3.0 SP5 and later
Redirection Allow Allow
Cross-Domain Partial Allow (Zone Policy) Partial Allow (Zone Policy)
Cross-Port Disallow Disallow
Mixed Protocol Disallow Partial Allow (HTTP to HTTPS only)


Web Applications