getButterfly Logo getButterfly

Internet Explorer Beta 2 has been live for a couple of weeks. Sunava Dutta , a program manager focused on improving AJAX in the browser.

The AJAX updates we’ve chosen for Beta 2 focus on maintaining cross-browser compatibility and the feature sets that developers have thought would be the most useful. Without further ado, here they are.

XDomainRequest (XDR)

This is an object built from the ground up to make client-side cross-domain calls secure and easy. To reduce the chances of inadvertent cross domain access, this object requires an explicit acknowledgement for allowing cross domain calls from the client script and the server. Additionally, it reduces the need for sites having to resort to the dangerous practice of merge scripting from third parties directly into the mashup page. This practice is dangerous because it provides third parties full access to the DOM. All this comes with the added benefit of improved client-side performance and lower server maintenance costs thanks to the absence of a need for server farms for proxying.

During the Beta 1 timeframe there were many security based concerns raised for cross domain access of third party data using cross site XMLHttpRequest and the Access Control framework. Since Beta 1, we had the chance to work with other browsers and attendees at a W3C face-to-face meeting to improve the server-side experience and security of the W3C’s Access Control framework. As a result, we’ve updated XDR to be explicitly compliant with syntax and directives in the sections of Access Control for requesting simple public third-party data anonymously on the client! (Section 5.1.3 in the Access Control Process Model)

The updates to XDR from Beta 1 allow IE8 to request data from the domain’s server by sending an Origin header with the serialized value of the origin of the requestor. IE8 Beta 2 will only return the response if the server responds with Access-Control-Allow-Origin: *, instead of allowing the XDomainRequestAllowed: 1 header as we did in Beta 1. Other changes include support for relative paths in the open method, and restricting access to only HTTP and HTTPS destinations.

Cross-document Messaging (XDM)

Cross-document messaging is another powerful cross-domain feature that I’ve blogged about in the past. Rather than make a backend request to a remote Web service, this allows sites hosting third-party IFrame-based “gadgets” or components to communicate directly with the parent, without unsafely violating the same site origin policy. This has advantages including improved performance and reliability, as developers don’t have to resort to workarounds that behave differently between browsers and have unwanted side-effects. This technique also removes the need for embedding third-party script in your page, lessening the chance of potential information disclosure vulnerabilities like the disclosure of your sensitive data (such as information in your social network profile) to third parties without your consent.

Beta 2 updates here include moving the onmessage handler from the document object to the window object to better align with the updated HTML 5.0 draft.

window.attachEvent(“onmessage”, HandleMessage);

We also replaced e.URI with e.origin, which is serialized form of “scheme” + “host” + “non-default port”. This is far safer as the URI can carry potentially sensitive information from the origin site that is not needed by the recipient for the decision to grant or not grant access.

if (e.origin == ‘’)
// process message text

Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.

frameOther.postMessage(“This is a message”, “”);

DOM Storage

Today, web pages use the document.cookie property to store data on the local machine. Cookies are limited in capability by the fact that sites can only store 50 key/value pairs per domain. Furthermore, the cookie programming model is cumbersome and requires parsing the entire cookie string for data. While cookies are useful for marking transitions and changes on the client to the server as they are sent with the request headers in chunks of up to 4KB, IE8 brings better alternatives for scenarios involving persisting data on the client and distinctly maintaining sessions in different tabs. The W3C’s HTML 5 DOM Storage objects provide a much simpler global and session storage model for key/value pair string data. Sites can store data for the life of a tab or until the site or user clears the data.

Updates for Beta 2 include changing the name of the persistent globalStorage attribute to localStorage and the removal of the need to specify the domain when writing to the localStorage

// Store a key-value pair.

Finally, we also included improved support of the updated onstorage HTML 5.0 event returned when the storage is changed. We now return the URI when the local storage is changed, so that handlers for pages can know who carried out the latest transaction in the storage space in addition to providing the source to the window of the origin. Furthering the good news, the HTML 5.0 Working Group has incorporated the clear method, which we shipped in Beta 1, into the draft. This essentially allows for script to clear all items accessible in its storage space without having to iterate though the keys.

Connectivity Event

The navigator.onLine property and online/offline events now work on Windows XP as well as Windows Vista. The work to enable this was not trivial, as connection awareness in Windows XP is not quite as advanced as Windows Vista. That said, this will be extremely beneficial for developers, who we believe shouldn’t have to worry about OS differences. The value of connectivity events is particularly appealing when used in conjunction with the localstorage, where data can be cached in case of network loss!


Introducing the XDomainRequest object in IE8 hasn’t diverted our attentions from constantly tweaking and improving XMLHttpRequest, which will continue to be our flagship object for same-domain communications. Post-Beta 1 energies here have focused on a few bug fixes around reliability and working with the Web Apps Working Group to clarify and improve the draft specification, our compliance with it, and W3C public test cases. A timeout method introduced here in Beta 1 for the convenience of developers is currently being evaluated for adoption in the XMLHttpRequest spec.

// Sets timeout after open to two seconds.
xhr.timeout = 2000;

ToStaticHTML, to JSON, and fromJSON

What do you do with the strings returned from third parties using XDomainRequest or Cross-document Messaging? In today’s world of increasing script injection and Cross-site Scripting (XSS) attacks, having the option of passing these through a safe parser comes as a welcome relief. As detailed in Eric Lawrence’s post on Comprehensive Protection for IE8 Security, toStaticHTML provides a powerful way of sanitizing your strings by purging potentially executable content.

window.toStaticHTML(“This is some <b>HTML</b> with embedded script following… <script>alert(‘bang!’);</script>!”);

//will return:
This is some <b>HTML</b> with embedded script following… !

In addition, IE8 Beta 2’s JSON.stringify and JSON.parse methods provide improved performance as opposed to non-native Javascript serializers and deserializers. Our implementation is based on the ECMAScript 3.1 proposal for native JSON-handling which uses Douglas Crockford’s json2.js API. In addition to the performance benefits of going native, the JSON parser provides a safe alternative to the eval() method, which has been a common and dangerous way to revive JSON objects, and could allow arbitrary script functions to execute.

Other Features

AJAX Navigations has undergone minimal changes since Beta 1. We’ve got some new code samples and overview documentation on this for Beta 2 on MSDN. Improved connection parallelism per host has also undergone a few tweaks and will command its own post soon.


We’ve worked in standards to make the AJAX experience for developers better. Beta 2 implements the changes mentioned above. Moving forward, we will continue to partner with members in the W3C on a variety of topics including advancing draft specifications. Strong developer adoption of these features is a priority and we’re focusing on help sites transition to integrating these features. For code samples for the AJAX feature set, please refer to our IE8 AJAX Beta 2 Hands on Labs. In case you’ve wondered who the ‘we’ in the AJAX core development team is, below is a photo (unedited, red eyes included) that puts a few faces to the names that pop up occasionally on blogs and mailing lists! Enjoy!

Subscribe to getButterfly Blog

Once a week or so we send an email with our best content. We never bug you, we just send you our latest piece of content.

If you found any value in this post, agree, disagree, or have anything to add - please do. I use comments as my #1 signal for what to write about. Read our comment policy before commenting! Comments such as "Thank you!", "Awesome!", "You're the man!" are either marked as spam or stripped from URL.

Leave a Reply

Your email address will not be published. Required fields are marked *