N
NewsBot
Sunava Dutta here, a program manager focused on improving AJAX in the browser! Now that Internet Explorer 8 Beta 2 is out, I want to write about some of the latest rounds of enhancements we’ve made. As many of you may recall, back in March we discussed a set of developer experiences in AJAX across scenarios such as client-side cross-domain data access, local storage, and navigation state management among many others. The good news is our team has been working since Beta 1 to tweak and update our implementations based on feedback from developers (thanks for your contributions!) and ongoing updates to the W3C standards drafts on which most of these implementations are based or have been submitted for consideration. Not content with doing just that, we also added a few new features for developers. More on that later…
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 == 'http://www.contoso.com')
{
// 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 or wildcard .
frameOther.postMessage("This is a message", "http://example.com")
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
[SIZE=10pt]// Store a key-value pair.
localStorage.setItem("FirstName","Sunava") [/SIZE]
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!
XMLHttpRequest
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.
//Calling:
window.toStaticHTML("This is some HTML with embedded script following... !")
//will return:
This is some HTML with embedded script following... !
In addition, IE8 Beta 2’s toJSON and fromJSON methods provide improved performance as opposed to non-native Javascript deserializers and serializers. 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.
Summary
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!
Sunava Dutta
Program Manager
From top left: Sharath Udupa (Developer), Gideon Cohn (Test), Zhenbin Xu (AJAX Senior Developer, Alex Kuang (Test) and Karen Anderson (Test)
From bottom left: Sunava Dutta (Program Manager) and Ahmed Kamel (Developer)Missing from this photo are Françoise Louw (Test), Adrian Bateman (Program Manager) and Gaurav Seth (Developer)
More...
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 == 'http://www.contoso.com')
{
// 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 or wildcard .
frameOther.postMessage("This is a message", "http://example.com")
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
[SIZE=10pt]// Store a key-value pair.
localStorage.setItem("FirstName","Sunava") [/SIZE]
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!
XMLHttpRequest
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.
//Calling:
window.toStaticHTML("This is some HTML with embedded script following... !")
//will return:
This is some HTML with embedded script following... !
In addition, IE8 Beta 2’s toJSON and fromJSON methods provide improved performance as opposed to non-native Javascript deserializers and serializers. 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.
Summary
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!
Sunava Dutta
Program Manager
From top left: Sharath Udupa (Developer), Gideon Cohn (Test), Zhenbin Xu (AJAX Senior Developer, Alex Kuang (Test) and Karen Anderson (Test)
From bottom left: Sunava Dutta (Program Manager) and Ahmed Kamel (Developer)Missing from this photo are Françoise Louw (Test), Adrian Bateman (Program Manager) and Gaurav Seth (Developer)
More...