This makes use of the new Access-Control-Check header that has been inching its way through standards committes for the past few years. It works like this: 

1. Script running in the browser makes a request for a URL outside the current document’s domain
2. The browser retrieve the requested page and examines the page’s headers for an Access-Control-Check header.
3. If the page does not have an Access-Control-Check header, the browser fails the request and the script never sees the data.
4. If the page has an Access-Control-Check header but the domain(s) listed in the header don’t match the domain of the document making the request, the browser fails the request and the script never sees the data.
5. If the domain of the current document matches the domain spec in the Access-Control-Check header, the browser passes the data through to the waiting request in the script.

Existing web pages are automatically excluded from cross-domain requests.  That is to say, script can request it and the browser will actually fetch the page, but the script will never see the results.  This is slightly different from how older browsers handle cross-domain requests – the request is shut down when the browser notices that the requested URL doesn’t match the current document’s domain, before anything crosses the wire. 

It seems conceivable to me that under this Access-Control-Check scheme, malicious web pages could launch a distributed Denial of Service attack against a particular server using cross-domain requests.  It doesn’t matter that the script never actually receives the data, the damage has already been done by requesting the page from the target server.  Is there any way for the server to ignore such requests?  I don’t know.  I’m sure the standards committees have discussed this at length.

This caveat aside, it’s exciting to see cross-domain support working its way into the major browsers.  I look forward to tinkering with it in IE8.

Check out the video on Adrian’s blog post.  You’ll probably want to download the .wmv directly to view it full screen in your local video player, as the video box in the blog post is far too small to see what is going on on the screen and the Flash player doesn’t appear to provide any way to zoom it up to a more useful size.  Odd.

Found via Ajaxian

One of the most aggrevating aspects of debugging cross-domain JavaScript is that JavaScript debuggers do not provide the same degree of omniscience we have come to expect from full-featured desktop application debuggers. The reason is that the debugger operates inside the browser, rather than above the browser.  To evaluate an expression, the debugger has to ask the browser’s JavaScript engine for the element values, or to evaluate the expression itself. Since the debugger is relying on the browser for evaluation, and the browser has access firewalls all over the place to implement same-domain policy restrictions, the debugger can’t see anything more than what the JavaScript itself can see.  A debugger attached to the execution context of a top level HTML page can’t see inside the iframes sitting on that page if the iframes are showing pages from a different domain.

This is fixable, but I doubt that it will ever be fixed. I suspect it would be a major restructuring of the browser code to allow a debugger to circumvent the browser’s security restrictions and see JavaScript state from all domain contexts concurrently. Even just a casual mention of this idea to Mozilla or Microsoft browser teams draws up such fear in their eyes that you change the subject to avoid someone going postal. I can’t really blame them – both browser code bases are huge and hairy, and infamous for inflicting great gouts of pain on well-meaning tinkerers who venture too far into the forest. 

Besides, it’s fair to say that the browser teams’ first priority is data security and safety. Omniscient debugger support is understandably lower on their priority list.

At any rate, while I was poking and prodding my cross-domain experiments trying to get a mental picture of how code reality was diverging from the whiteboard spec, I would occasionally notice an odd artifact out of the corner of my evaluator.  Well, this is JavaScript - odd side effects are the norm. On one of these sorties I noticed that the window.name property was preserved across reloads of an iframe.

Now that’s odd.

My tinkering took off on a wild tangent.  Passing a lot of data in one string and round-trip would certainly be faster than doing it in multiple smaller round trips required by fragment identifier messaging (FIM).  However, the more I dug into it the more I found that needed to be chased down.  Frustrated and out of time, I pushed a note onto the “investigate this further” queue and forced myself back onto the plan of record.

Fast forward to 2008.  Kris Zyp has implemented a cross-domain transport for the Dojo JavaScript library using window.name. Kudos to Zyp for doing the legwork to turn the window.name oddity into a usable data transport pipe and shore up the holes and security vulnerabilities of the raw technique. 

I read his post (discovered via Ajaxian) with skepticism, armed with an array of  ”Yeah, but what about…” challenges and security issues I vaguely recall running into in my late night tangent.  Zyp knocked them all down one by one in his detailed writeup.

Well done!

note: The WebClient class does not currently support cross-domain calls.

Say what?

The article then proceeds to show how to make an XML call using Silverlight’s WebClient class, and oh by the way it’s a cross domain call.

Nice job, guys.

Here’s what that article probably meant to say, but managed to get lost in the words:

Silverlight’s WebClient class supports cross-domain HTTP requests *IF* the target server allows cross-domain requests. 

It really is that simple. 

To configure a server to support cross-domain requests, read “How to: Make a Service Available Across Domain Boundaries“.