flXHR FAQ
Q: How come flXHR looks so much like XMLHttpRequest? A: flXHR was specifically designed to implement a completely API-compatible, drop-in replacement for the browser's native XMLHttpRequest (XHR) object. The reasons for this are numerous (and probably obvious), but include the ability for existing code to have very minimal alteration to leverage flXHR. In addition, since most other Javascript frameworks (Dojo, Prototype, jQuery, etc) use the native XHR object behind the scenes, and rely on its API and behavior, flXHR was designed so that it could easily be replaced in the XHR factory functions of those frameworks and used as-is, removing the need for those frameworks to fall back on inefficient (or insecure) workarounds such as the IFRAME proxy, server-side proxy, or dynamic script tag loading.
Q: What can flXHR do that XMLHttpRequest can't do? A: There are many things that flXHR does which the native XMLHttpRequest (XHR) object (at least in the current generation of modern browsers prior to FF3 and IE8) cannot do:
flXHR is capable of making cross-domain calls from client to server directly and only through client-side technology, without any server-side proxying. Other Javascript/HTML techniques for this include IFRAME's and dynamic script tags. However, both of these suffer from things which flXHR does not. For one thing, both of those workarounds, while client-side only, have no built-in mechanism for author-controlled (server-side) authorization. flXHR does, because it makes use of Flash Player's security mechanism with server-side cross-domain policies.
In addition, the IFRAME approach makes use of timers to query the hidden object for updates, and must chunk them up into small pieces to fit in the 'url' property as url-fragments. The dynamic script tag approach requires all responses to come back as JSON/executable Javascript. flXHR directly sends the entire request all at once, and receives the entire response all at once, without chunking, ugly timers, or script-block evaluation mess. flXHR implements a sensible event-callback mechanism, identical to that of the native XHR object, for dealing with the responses from a request, something neither of the other two workarounds even come close to achieving.
flXHR has support for send/response sequence timeouts, which are only being introduced as of IE8. This means that the native object's behavior in all browsers other than IE8 is deficient in this area, requiring custom wrapping code to accomplish this. flXHR does this for you as part of the consistent interface, which brings this behavior to all flXHR supported browsers (basically, those capable of hosting the Flash Player plugin v9+).
flXHR implements a robust, detailed error callback mechanism for dealing with many different error scenarios, including security authorization failure, timeouts, dependency errors, Javascript exceptions, connection drops, server-side errors, etc. The native XHR object has only a basic method for error handling implemented through the onreadystatechange handler, and such limited error cases must be detected in cross-browser dependent tricky ways.
flXHR provides convenience methods for configuring multiple settings at once, resetting the internal state of the object, and even an explicit destructor for killing the object's memory usage/event bindings for better client memory management.
flXHR can be configured not to do conversion of the response into the binary 'responseBody' property or the XMLDOM node 'responseXML' property, which allows an author to squeeze more performance out of the flXHR object if the known response will be text, HTML, or even JSON and doesn't require the extra conversion.
Q: What can XMLHttpRequest do that flXHR can't do? A: There are a few (minor) areas where the current implementation of flXHR (mostly related to Flash Player plugin limitations) cannot perform the same completely as the native XMLHttpRequest (XHR) object API, including:
flXHR cannot be run in a browser that does not have sufficient Flash Player plugin support, whereas XMLHttpRequest (XHR) is native to almost all modern browsers.
flXHR currently has no access to any response headers that come back to the client from the server. The API functions for this functionality are empty stub functions for now.
The behavior of the Flash Player plugin when sending certain types of request headers is unclear at this point. Further testing, and author-use-at-your-own-risk (or, your-mileage-may-vary YMMV) are the position on this topic at this point.
The Flash Player plugin does not support synchronous communication, so the 'asynch' parameter to open() is ignored and always true. However, it's my opinion that this feature is ill-suited for web applications in a browser anyway, as it has the very negative side effect of locking up the browser interface completely during the transmission/receive. Other 'best-practices' include disabling some parts of the page/controls as appropriate while waiting for response from the asynchronous request.
Technically, flXHR cannot complete its full initialization until after the DOM of the page is ready (so it can add the flXHR.swf object to the page). As such, it will not actually perform any calls back to the server during DOM load. However, flXHR is capable of queueing all commands called on it immediately after the initial new() operator instantiation, even if it has to wait for the DOM to be able to process them. So code which relies on being able to call the XHR requests before page load will still be syntactically identical, though the flXHR request won't even be sent off before DOM load, whereas an XHR request may be sent off a little sooner.
Since it's unlikely that many pages are actually *relying* on a full XHR request/response cycle to complete *before* even the DOM completes, this limitation of flXHR is greatly reduced in intensity. Most likely, the response from a native XHR request would come after the DOM load anyway, as would flXHR's response, so behavior may be the same with slightly longer wait times in some cases. These additional delays should be very minor in the 10's or 100's of milliseconds at most.
When you consider the potential slow-downs of the flXHR model compared to the overhead needed by the other cross-domain workarounds available right now, flXHR should perform similar or better, considering the overhead tradeout differences between those approaches and flXHR.
Q: How is flXHR different (or better) than Fjax? A: There are a number of important differences between flXHR and the Fjax solution External Link first released back around 2006:
First and foremost, Fjax does *not* implement the same (or even close) API as the native XHR object in the browser. flXHR *does*. flXHR does so because flXHR was designed to be a drop-in replacement for native XHR, so that it can be used exactly like the native XHR, and that it can easily be integrated into JS frameworks that already know how to speak the XHR API.
The Fjax API appears to give no control over where the cross-domain policy should be loaded from, so cross-domain calls are less flexible than with flXHR which does have an API ability to set the cross-domain policy file location manually. This gives the author much more control over the security of their application.
Fjax is only directed at getting XML content from a server. flXHR can get *any* kind of content from a server (HTML, CSS, JS, JSON, XML, binary, text, etc).
Fjax *does* write the HTML embed code for its SWF instance. However, it appears from the API documentation that Fjax's GetXML() function (and its resulting SWF embedded instance) can only be used once to embed the SWF and make the call to the server. Subsequent calls by Fjax would need to be made by additional embeddings. flXHR creates a flexible, reusable object basically identical to the native XHR object so that it can be instantiated once and used any number of times during the page's lifetime. flXHR uses the very mature, standard, SWFObject library to do its embedding, which is much more robust and reliable than the embed code that Fjax relies on.
Fjax also has none of the important API extensions that flXHR implements, including a robust error-callback mechanism, plugin version detection and inline auto-update, etc. flXHR was designed specifically to be the *complete* solution for all types of Flash based AJAX (especially cross-domain communication). If an author knows about or can write against the very simple, straightforward XHR API, then they can easily use flXHR and get all the additional benefits. No need to learn a different API like with Fjax.
flXHR targets specifically the most secure, robust (and current as of this writing) release of the Flash Player plugin, 9.0.124, which has the best of Adobe's mature security model implemented for cross-domain communication. Fjax tries to have backward compatibility with previous versions of the plugin and therefore will be less secure.
Q: How is flXHR different (or better) than SWFHttpRequest? A: There are a number of important differences between flXHR and the SWFHttpRequest solution External Link released back in Dec 2007:
First, SWFHttpRequest does implement a "close" API to the native XHR, similar to how flXHR implements it. However, by the nature of SWFHttpRequest's method of inclusion/embedding .SWF in the page (see the next note), it is not as easy to adapt and use with some JS frameworks. Their page has some simple examples of this, but other frameworks prove to be more complicated to use, because they rely on the ability to instantiate new 'XHR' instances on the fly, and SWFHttpRequest requires that each instance which will be used must already be planned out by the author and HTML embedded and prepared. flXHR on the other hand can, by virtue of the SWFObject library, add instances of the .SWF as needed, automatically as part of object instantiation.
As mentioned above, SWFHttpRequest does not add the .SWF file to the page for the author. The author must put the ugly HTML object and embed codes into the page manually. This does not scale, and does not make SWFHttpRequest flexible or easily reusable. flXHR on the other hand is accessible as easily as instantiating a simple Javascript object with the "new" keyword. The object does all the rest of the work, using the SWFObject library to add the .SWF to the page, make it totally invisible, and prepare it to be used by the Javascript.
Just like with Fjax, SWFHttpRequest appears to give no flexibility/configuration over the location of the cross-domain policy file. flXHR of course makes it easy to control the location of this policy file, which makes it easier for the author to make sure their policy file is sensible and as secure as it can be for their application. Default locations are great as defaults, but often they need to be overriden. flXHR has this ability built in.
SWFHttpRequest's API is a good but bare-bones implementation, which lacks many of the helpful additions of the flXHR API, including robust error-callback handling, timeouts, plugin version detection/updating, etc.
flXHR targets specifically the most secure, robust (and current as of this writing) release of the Flash Player plugin, 9.0.124, which has the best of Adobe's mature security model implemented for cross-domain communication. SWFHttpRequest tries to have backward compatibility with previous versions of the plugin and therefore will be less secure.
Q: How is flXHR different (or better) than FlashXMLHttpRequest? A: There are a number of important differences between flXHR and the FlashXMLHttpRequest solution External Link first released back in 2006:
Like SWFHttpRequest, FlashXMLHttpRequest implements a "close cousin" to the native XHR API. But it's not exact, which will make its integration with existing XHR-like code or JS frameworks more difficult than with flXHR, which is exact.
There are some significantly higher requirements for this 'XHR' implementation, including requiring the full Dojo framework (an old, 0.3 version of it in fact!). flXHR on the other hand only requires a much smaller but still very helpful CheckPlayer library which uses the equally helpful SWFObject library for SWF operations.
FlashXMLHttpRequest uses Dojo to embed it's .SWF instance. flXHR on the other hand uses the more standard, stable, mature SWFObject library for its SWF operations, which makes flXHR more robust with its ability to embed the SWF to the page. In addition, with CheckPlayer's functionality, flXHR can initiate an inline auto-update of the plugin if it needs it.
Just like with Fjax and SWFHttpRequest, FlashXMLHttpRequest appears to give no flexibility/configuration over the location of the cross-domain policy file. flXHR of course makes it easy to control the location of this policy file, which makes it easier for the author to make sure their policy file is sensible and as secure as it can be for their application. Default locations are great as defaults, but often they need to be overriden. flXHR has this ability built in.
FlashXMLHttpRequest's API lacks many of the helpful additions of the flXHR API, including robust error-callback handling, timeouts, plugin version detection/updating, etc.
flXHR targets specifically the most secure, robust (and current as of this writing) release of the Flash Player plugin, 9.0.124, which has the best of Adobe's mature security model implemented for cross-domain communication. FlashXMLHttpRquest tries to have backward compatibility with previous versions of the plugin and therefore will be less secure.
Q: How is flXHR different (or better) than F4A? A: There are a number of important differences between flXHR and the F4A solution External Link:
F4A is the closest to the approach that flXHR takes of any of the previously mentioned Flash-AJAX approaches. It even uses SWFObject to place the SWF on the page, just like flXHR, although flXHR uses the much more advanced and efficient SWFObject 2.1 library, whereas F4A uses SWFObject 1.5 syntax, which had many bugs and drawbacks.
F4A is a "close cousin" to the native XHR API. But it's not exact, which will make its integration with existing XHR-like code or JS frameworks more difficult than with flXHR, which is exact.
Just like with the other approaches mentioned above, F4A appears to give no flexibility/configuration over the location of the cross-domain policy file. flXHR of course makes it easy to control the location of this policy file, which makes it easier for the author to make sure their policy file is sensible and as secure as it can be for their application. Default locations are great as defaults, but often they need to be overriden. flXHR has this ability built in.
F4A's API lacks many of the helpful additions of the flXHR API, including robust error-callback handling, timeouts, plugin version detection/updating, etc.
flXHR targets specifically the most secure, robust (and current as of this writing) release of the Flash Player plugin, 9.0.124, which has the best of Adobe's mature security model implemented for cross-domain communication. F4A targets Flash 8+, which is good, but will be less secure than flXHR with v9.0.124.