From Ajax Patterns
|Revision as of 01:39, 10 May 2009
Shadedecho (Talk | contribs)
← Previous diff
Shadedecho (Talk | contribs)
|Line 49:||Line 49:|
|= Related Patterns =||= Related Patterns =|
|== Client-side Proxies ==||== Client-side Proxies ==|
In A Blink
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.
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.
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:
There are various other client-side proxy implementation patterns, such as:
- Iframe proxy Iframe Proxies (not yet written)
- Window-name proxy Window.name 'proxy' (not yet written)
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.
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.