Using aiScaler to address AJAX cross-domain limitations
Posted by Max Robbins on October 25th, 2010aiCache’s pattern and origin server tagging (os_tag directive) is ideally suited for addressing the well known limitation of AJAX cross-domain scripting.
As you may well be aware, the XMLHttpRequest object (aka XMLHTTP object in Internet Explorer) is the centerpiece of today’s AJAX-driven web applications. Many a popular site owes its rich functionality and responsive interface to the use of AJAX.
AJAX has one significant security constraint; one cannot create an AJAX request to a domain different from the one from which the Javascript itself was downloaded. For example, if one has AJAX functionality embedded in news.acme.com/ajax.js, the AJAX calls from the said JS file can only address URLs at news.acme.com and not any other domain, or even a subdomain of acme.com. You shall see that this limitation can be easily addressed by using aiScaler os_tag setting.
Let’s imagine that news.acme.com has “newsmaker” page – a mash-up of data about celebrity of the day. The page displays the editorial content about the person, along with user-submitted comments and may be latest RSS-driven news about the celebrity.
We also display the search results so that users can see prior content that was published by Acme. The comments, the search results and the latest RSS data are embedded into the page client-side, using AJAX. So as new comments are posted and RSS feeds are updates, the page refreshes itself without user having to reload it.
To obtain this functionality, there’s some JS code, downloaded from news.acme.com that needs to access URLs at comments.acme.com, search.acme.com and rss.acme.com. The three subdomains we mentioned could be hosted in different environments and/or datacenters. Some could be .Net-based, some PHP-based and some developed in Java.
Some environments could be white-labeled from an external provider. No matter the technology, you can see that accessing three different subdomains presents a problem. It won’t work unless one of the two different technologies is deployed to address it:
a client side Flash proxy
(see http://blog.monstuff.com/archives/000294.html)
a server-side proxy solution
Flash proxy solution requires Flash support in the user browser.
While almost ubiquitous these days, such Flash support is not present in quite a number of mobile devices, including Android-based ones and the latest product from Apple, the iPad. From the looks of it, we can take as a given that this Flash-deficiency is not likely to get rectified any time soon.
Server-side proxy solution doesn’t suffer from such limitations and is completely browser and client-agnostic (although, clearly, for any of AJAX to work, client browser must support AJAX). Instead of trying to access the required functionality directly on the three different sub-domains, we instead request the functionality from news.acme.com and have aiScaler servers to direct (relay) the requests to proper sub-domains.
So let’s provide a configuration file snippet showing how one can configure aiScaler servers that accelerate news.acme.com, to transparently forward requests, based on the request URLs, to different origin servers.
We will assume that requests sent to news.acme.com/search.php?anything should be sent to search origin servers.
Likewise requests to news.acme.com/comments.do?anything should be sent to comments origin servers. Lastly, requests sent to news.acme.com/rss.apsx?anything should be sent to rss origin servers. In all three cases, we will rewrite the Host header to match the origin farm we choose.
….
website
hostname news.acme.com
pattern /search.php simple 1m # Cache for 1 minute
os_tag 2 # Send it to search servers
sub_hostname search.acme.com
pattern /comments.do simple 1m # Cache for 1 minute
os_tag 3 # Send it to comments servers
sub_hostname comments.acme.com
pattern /rss.aspx simple 1m # Cache for 1 minute
os_tag 4 # Send it to RSS servers
sub_hostname rss.acme.com
….
origin 1.1.1.1 80 # Regular origin servers for news.acme.com, no os_tag !
origin 1.1.1.2 80 # Regular origin servers for news.acme.com, no os_tag !
origin 2.2.2.2 80 2 # origin servers for search.acme.com, note os_tag of 2 !
origin 3.3.3.3 80 3 # origin servers for comments.acme.com, note os_tag of 3 !
origin 4.4.4.4 80 4 # origin servers for rss.acme.com, note os_tag of 4 !
As you can see, with a very straightforward and easy-to-manage configuration setup, we can now joggle, on the fly and completely transparently to the end users, requests amongst 4 different subdomains. All while caching responses, having real-time view of the traffic statistics, along with ability to shield end-users from any issues at the said sub-sites.
Please note that such request relaying happens completely transparently to end users, in a sense that it is aiScaler that obtains the actual response, no HTTP redirects are sent to the requesting browsers (and even if they were sent, such redirect still won’t work).
When any of the sub-sites are hosted by external providers, we don’t require any involvement from them, to accomplish such setups. Also, with such hosted-API arrangements, where charges are based on volume of requests, we can save significant amount of money by caching responses.