This article discusses a few ways to get around the security constraints that we have to live with in the browsers theses days, in particular, only being able to talk to your domain via XHR.

The article walks you through three potential solutions:

Application proxies. Write an application in your favorite programming language that sits on your server, responds to XMLHttpRequests from users, makes the web service call, and sends the data back to users.

Apache proxy. Adjust your Apache web server configuration so that XMLHttpRequests can be invisibly re-routed from your server to the target web service domain.

Script tag hack with application proxy (doesn’t use XMLHttpRequest at all). Use the HTML script tag to make a request to an application proxy (see #1 above) that returns your data wrapped in JavaScript. This approach is also known as On-Demand JavaScript.

I can’t wait for Trusted Relationships within the browser – server infrastructure.

I’m using on-demand JavaScript successfully in a cross-domain AJAX application. I used the excellent browsershots.org to test the technique in all the common browsers and it works perfectly in all but Konqueror, and I believe the latest version of Konqueror (in beta at the time of writing) will support it.

I think using a ‘bookmarklet’ falls into this category. The Mouseover DOM Inspector (http://slayeroffice.com/tools/modi/v2.0/modi_help.html) uses this approach, which is interesting. The main problem I suppose is when the code changes, the user must update the bookmarklet.

Comment by Jason Pollard — November 10, 2005

On-demand javascript is also the way of Jini ;-)

Lately, I’ve been considering how to combine Ajax and Jini. Tough problem since Jini assumes a JVM for the downloaded proxy. Using Jini surrogates is one possibility… I’m still thinking this one through.

Dion: Yes, I’m using what the article calls “DOM-Based On-Demand Javascript”, creating a script element programmatically and adding it to the head.

Comment by Richie Hindle — November 11, 2005

We have always used Apache’s Mod proxy to achieve cross domain and cross port aggregation and rewriting.

Apache kicks but for any static content, thus ones web app shouldn’t even touch it. Often different parts of the web applcation itself exist on different url/context or even different ports. The proxy feature enables one to partition the web application in a very reliable and flexible manner. Normally we would be running at least 3 different parts of a web app by default :
1) Static content (always apache)
2) Dynamic page content usually servlets running under Jetty
3) AJAX controller and dynamic REST app running under jetty (canm actually change these settings)

Also Apache can cache some of the stuff which really reduces your web app load