Thursday, March 26, 2009

Updated W3C draft on "Cross-Origin Resource Sharing"

pencil icon, that"s clickable to start editing the post

About a year ago I wrote about W3C draft on a 'policy' to allow webapps to selectively loosen the same-origin restriction and now they've release a new working draft: Cross-Origin Resource Sharing. I haven't checked that status of the project but hopefully they are closing up to the final recommandation after more than a year's work. The only clue is from the section on status of the document where it states It is expected that this document will progress along the W3C Recommendation track, which isn't all that exact.

The abstract defines the essence as:

This document defines a mechanism to enable client-side cross-origin requests. Specifications that want to enable cross-origin requests in an API they define can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.

The specification defines af total of 3 HTTP request headers and 5 HTTP response headers:

  • Origin
  • Access-Control-Request-Method
  • Access-Control-Request-Headers
  • Access-Control-Allow-Origin
  • Access-Control-Max-Age
  • Access-Control-Allow-Credentials
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers

I haven't read the specification in great detail but it looks like this will make web 2.0 mashups a lot easier, makeing it possible to make requests to different hosts based on a formal policy. As for inter-document interactions like in iframe scenarios I'm not sure, but I think it follows along since if to hostnames declare that they are an associated common domman I would expect these restraints to loosen as well freeing us for using semi-dirty hacks like double iframe communication.

0 comments :