Cross Domain Ajax: a Quick Summary

Here are a few of the most popular ways to do cross domain calls via JavaScript: proxies, JSON, and Flash.

Cross domain proxy

This is one of the most common approaches. Your script calls your server, your server makes the call to the remote server and then returns the result back to the client. There are some definite advantages to this approach: you have more control over the entire lifecycle. You can parse the data from the remote server, do with it what you will before sending it back to the client. If anything fails along the way, you can handle it in your own way. And lastly, you can log all remote calls. WIth that you can track success, failure and popularity.

Cross domain JSON

For this to work, the remote server needs to be set up to handle this. It needs to accept an additional parameter: a callback function. Then, to make the remote request, you insert a new script tag into your page with which will allow you to specify a remote URL. The reponse back will load a JSON object as a parameter of the callback function you specified in the request. Yahoo, for example, has implemented this feature in their web services API's. This is great because you can implement web service calls without ever needing a scripting language on your server. Check out Jason Levitt's article, JSON and the Dynamic Script Tag, on XML.com for more information.

Cross domain using Flash

Flash, by default, is much like Ajax in that you cannot request data from a remote server. However, you can enable this capability by placing a special XML file on the remote server to accept requests from other domains. With JavaScript's capability to interact with Flash, we can use Flash as a bridge for sending cross-domain requests. (XML.com has a nice write-up of this technique.) There are still some limitations to this technique, most of which seems to be limited to older versions of Flash. There's also the issue with users having Flash installed and enabled.

Sub-domains are still cross domains

One point to note and it's fairly subtle. Plenty of us have our sites running at www.example.com and at example.com. They both point to the very same place. To us, we see them as the same thing. But to an Ajax call, it's considered cross domain. Therefore, if you have to make an Ajax call to the same server, don't code the domain as part of the request; just use the path.

The Future

Some have already begun looking into establishing standards that could be implemented into future browsers, such as JSONRequest and ContextAgnosticXMLHttpRequest. JSONRequest seems the most promising but that could be because I prefer JSON over XML and see it as really gaining traction over the next couple years.

Published August 18, 2006 · Updated August 18, 2006

Conversation

13 Comments · RSS feed

Noah Winecoff said on August 18, 2006

Interesting technique, using flash as a bridge. Great Post!

Ruby on Rails said on August 18, 2006

Using flash as the bridge is the concept that the Lazslo on Rails project is trying to incorpporate to make Ruby on rails and ajax and a fine gui play nicely together also. I am watching the cross domain ajax to see how things develop since I think it has many interesting applications. Keep it up please.

Nick said on August 21, 2006

I agree with the use of relative paths in the calls, rather than including the full domain, I must say though imo it is well worth deciding upon which you want to use 'www' or no 'www', and then using a bit of script to redirect appropriately when the site is accessed via the wrong one.
One of the bigger advantages is to avoid duplication of your pages in search engine results, as this will actually bring your overall page weightings down.

Tanny O'Haley said on December 06, 2006

It's not only sub-domains, but directory paths too. www.example.com/web/util and www.example.com/app are considered different domains. I had to use document.domain = "example.com"; on all pages so that the directories could talk to each other's pages.

t3knomanser said on July 06, 2007

Holy crap, the cross-domain JSON scares me. That's amazingly dangerous! Really simple, sure- but wow, that's a lot of trust on the provider of the data.

Motin said on August 17, 2007

One implementation of the first method is AJAX Extended that sould be found on ajaxextended.com but that domain, the author and his company seems all to have vanished totally!

I found the client part of AJAX Extended here: http://www.ajaxlessons.com/?attachment_id=19

Anyone know where I can get a hold of the AJAX Extended PHP API source code which is needed as well...?

Motin said on August 17, 2007

Found a mirror finally - Google Code: http://google.com/codesearch?hl=en&q=show:M8cy5FPc_s0:A16F7hY_YnM&sa=N&ct=rdp&cs_p=http://svn.serebryakov.ru/ajaxextended/trunk

Girish said on November 16, 2007

Another interesting approach to the same cross domain problem with a proxy. This time with an added functionality to handle the cookies returned by the requested page.

http://icodeleague.110mb.com/cmsimple/index.php?Website_Development:Cross_Domain_AJAX

Henrik said on November 21, 2007

Yet another solution for PHP developers:

http://redotheweb.com/?p=4

Jason Miller said on September 13, 2008

You can actually make a "real" Cross Domain Request using iframes (yes, the devil) - though you have to be able to stomach their use. I created a JavaScript library to bring a little more ease to the process here: http://developit.ca/XDR-JavaScript-Cross-Domain-Request/.

Kyle Simpson said on January 30, 2009

I've got a project called 'flXHR' http://flxhr.flensed.com/ which is a flash+javascript direct re-implementation of the native XHR api, but using an invisible flash object to allow cross-domain requests. Since it's API is identical, it's an easy drop-in replacement for native XHR, and can thus be used very easily with any existing code or JS frameworks (like jQuery, Dojo, etc).

Since it uses flash (specificaly 9.0.124+), it utilizes the newest, strongest implementation of Adobe's cross domain server opt-in policy to authorize such communication, which makes the communication using flXHR inherently more secure, more efficient, and less hacky than many of the other common cross-domain workarounds available right now.

In addition, by centering on the native XHR API, flXHR becomes an effective "future-proof" drop-in solution until such time as browsers extend those API's to allow for native cross-domain-safe communication.

Stefano Crosta said on February 24, 2009

Nice summary Jonathan!

At dev.mixendo.com we are working to facilitate bulding mash-up applications, and the same-origin policy is the first lock to break.

We implemented an improved version of the "cross-domain proxy" solution described here, the only one that does not require any access to the servers you want to connect to. Improved, because we also manage cookies for persistent sessions, and have an improved security model limiting cross-domain to a self-declared list of hosts that the user will be able to validate.

Usage of our service is extremely simple, you integrate our javascript and keep using the XMLHttpRequest as before... except now it's cross-domain enabled!