First and foremost, it’s worth noting the current limitation on cross-domain requests with the XMLHttpRequest object. As you may, or may not be familiar with, all browsers implementing the XMLHttpRequest object have also implemented a security feature called same-origin, which ensures that a request made with the XMLHttpRequest object must be to the same remote server of the originating script. That is, the requesting endpoint can only request resources from the same origin. An attempt to request resources from another origin will fail. JavaScript files imported into HTML documents by way of the <script src=”...”> tags are regarded as the same origin of the HTML document regardless of the physical origin of the script itself.

The same-origin security police is intended to control access to a remote hosts resources; that is a script originating on the host cannot make requests to resources on another domain such as It’s important to understand that browsers implementing the same-origin security policy compare the origin as string literals, meaning any alteration to the origin address will cause the request to fail. For example, altering the port number, the protocol used (changing from HTTP to HTTPS) or specifying the origin address as the IP address when it was previously identified as a hostname. All of which listed will fail the security check. Also note that the any path expressions of the URL are ignored in the check, that is the address and is identified as the same origin.

That said, to build a mashup application (one which makes use of multiple different cross-domain services) we must construct a proxy hosted on our server, from there our client-side code invokes the proxy, the proxy requests the remote resources and finally returns the result to the client-side code, however Microsoft has an solution, something that would greatly simplify the development of mashups, something that would require no proxy. The current structure of a mashup can be represented graphically in the following figure.


And, Microsoft’s answer is the XDomainRequest object depicted in the following figure.


With the XDomainRequest object, users of Internet Explorer 8 can make cross-domain requests directly from client-side code, notice the omission of the proxy service in the figure above. The XDomainRequest object can, however, only communicate with remote hosts that support XDR. The initial request sent from the client includes the request header XDomainRequest: 1. The connection will then only be completed with the remote host responds with the attribute XDomainRequestAllowed and a value of 1 in the response header.

The basic client-side code for invoking a cross-domain request is as follows.

// 1. Create XDR object
xdr = new XDomainRequest();

// 2. Open connection with server using POST method.“POST”, “”)

// 3. Send string data to server. 
xdr.send(“data to be processed”)

Finally, as with the XMLHttpRequest object, we can bind an event handler to the onProgress event, which is triggered when the remote host begins streaming data in regards to our request.

Internet Explorer 8 includes a few other pretty neat enhancements for AJAX developers. Take a look at the white paper. For details on constructing standard web services that can be used as proxies for mashups check out my book ASP.NET AJAX Programming Tricks.

I'm going to continue blogging about these new features, I'll demonstrate the construction of a remote service, which supports XDR and how the service can be invoked from client-side code. Stay tuned!