Flash-enabled XHR - Ajax Patterns

Flash-enabled XHR

From Ajax Patterns

(Difference between revisions)
Revision as of 01:39, 10 May 2009
Shadedecho (Talk | contribs)
Related Patterns
← Previous diff
Current revision
Shadedecho (Talk | contribs)
Related Patterns
Line 49: Line 49:
= Related Patterns = = Related Patterns =
 +== Javascript [[Web_Remoting]] ==
 +[[Web_Remoting]] The ability for Javascript to make asynchronous calls from within the page of the browser back to a server, without requiring the page to navigate away. This is the heart of the very common buzz-word "Ajax".
== Client-side Proxies == == Client-side Proxies ==

Current revision


In A Blink

JavaScript assisted by invisible flash helper proxy to make cross-domain Ajax calls.


How can you make cross-domain Ajax calls exactly like you make regular same-domain Ajax calls?


  • The browser already has a native XMLHttpRequest (XHR) object for making Ajax calls, and the API for that is more than capable enough to handle making cross-domain calls.
  • However, the object itself is not capable of doing so. The reason is that the native XHR object is restricted by the same-domain origin policy that all browsers now enforce.
  • New versions of the major browsers (IE, FF) are introducing entirely different objects for cross-domain Ajax calls, but naturally these are different from the native XHR object already present and written against, and sadly they are different from each other, which means we still don't have a good cross-browser way to do cross-domain Ajax.


Javascript+Flash Ajax calls, via flXHR (and others)

This is an API object clone replacement approach, with the following benefits:

  • Existing page code for making same-domain Ajax calls does not need to be changed, because the API for native XHR is emulated, and so the flash-enabled solution becomes a viable drop-in replacement for native XHR.
  • Flash's model for authorizing cross-domain communication involves a server opt-in policy which is strictly checked and respected by the Flash plugin (which means it cannot be hacked or changed by run-time web page application code).

The spirit of this solution is to use a flash swf instance as a proxy for cross-domain Ajax calls, which is an effective client-side alternative to the Cross-Domain Proxy pattern.

The key to this approach is to instantiate an invisible (technically 1x1 pixel) flash swf instance, and then wrap it in some javascript which exposes the same API functions as the native XHR object. The Javascript wrapper passes calls and request data to the flash "proxy".

The browser plugin first checks the target server for permission via its crossdomain.xml server opt-in policy (if found). If and only if authorized, the flash proxy then sends the request on to the server. It waits to hear back, and when it does, it forwards the response to the wrapper Javascript, which then exposes the data to the calling page code's application logic, just as if it were happening from the native XHR object.


At this time, flXHR is the only completely API compatible solution in this pattern, though many other projects out there implement to lesser degrees the same spirit of this pattern.

Some other options include:

Related Patterns

Javascript Web_Remoting

Web_Remoting The ability for Javascript to make asynchronous calls from within the page of the browser back to a server, without requiring the page to navigate away. This is the heart of the very common buzz-word "Ajax".

Client-side Proxies

There are various other client-side proxy implementation patterns, such as:

Cross-Domain Proxy

The Cross-Domain Proxy pattern relies primarily on a server-side proxy, which is not subject to same-domain origin restrictions and thus can make cross-domain Ajax calls as needed. However, the Flash-enabled XHR pattern specifically moves the "proxy" into the client-side (the browser), so an intermediate server proxy is unnecessary. Client-side proxies are particularly useful in creating dynamic mashups.

On-Demand Javascript

On-Demand Javascript Dynamic script tags -- not really a proxy per se, but yet another way around the same-domain origin policy.

Visual Metaphor

If you are in a foreign land which you don't speak the language, and you need to conduct some business, you can bring along a friend who speaks the native language as well as your own. You speak and conduct business by first asking your friend to translate for you and pass along your message to the intended recipient, and then waiting for him to translate the response back to you.

Want to Know More?

flXHR for cross-domain Ajax