Wednesday, June 25th, 2008

flXHR: Flash based XHR from flensed

Category: Ajax, Flash, JavaScript, Library

Kyle Simpson has announced a new family of opensource projects called flensed and the first project being flXHR which “utilizes javascript+flash to create a complete, literal drop-in replacement (by being API identical) for the native browser XHR (Ajax) communication mechanism. However, flXHR uses Flash Player’s security model to enable direct cross-domain communication, and also has a number of other very helpful extensions.”

There are a number of demos which illustrate how it easy it is to take the API-compatible flXHR and swap it to any of your favorite JS frameworks (Dojo, Prototype, YUI, ExtJS, etc) in place of its usage of native XHR… once the simple adapt/swap happens, everything else about the framework library communication works the same, because flXHR speaks the same familiar protocol and API, and so it really is what I like to call “set it and forget it” good.

Hasn’t this been done before?

There have been several other attempts at similar things before, including SWFHttpRequest, FlashXMLHttpRequest, Fjax, and F4A. However, all those fell short of the mark in different ways. On my site, there are comparison charts and detailed FAQ’s which show how flXHR stands up to these predecessors, and exceeds them in very important and powerful ways. I believe flXHR has accomplished its goal, which was to be *the* complete solution for SWF-based Ajax calls as an identical API-compatible drop-in replacement for native XHR, not to mention many helpful improvements including robust error callback handling, timeouts, and convenience configuration functions, to name a few.

Posted by Dion Almaer at 9:53 am

4.1 rating from 45 votes


Comments feed TrackBack URI

For the record, Flash does not send cookies with these requests (or in the case of Windows, sends IE’s cookies regardless of which browser you’re on??), is that still the case?

Comment by Schill — June 25, 2008

@Schill – I helped Kyle debug and evolve flXHR to be used with our current application to push out local content to remote servers (that whole mashup thing). Our implementation required no cookies, nor did it send any through flash.

If you are looking for cookies to maintain authentication, etc, I’m sure that some sort of solution could be put into place if cookies aren’t able to be transferred through flXHR.

Of course, Kyle is quite eager to improve the product in any way, so if you do find bugs/features lacking, he’s open to comments and suggestions.


~ Brian

Comment by Ipequey — June 25, 2008

Flash Player plugin maintains its own “cache” of information, similar to cookies, that is called the “Local Shared Objects”. You can set and retrieve flash cookies on sites. AFAIK, I don’t think it will automatically pick up on and forward the normal browser cookies along.

However, it seems theoretically possible that given the much easier Flash-Javascript brige (called “ExternalInterface”) which flXHR relies upon, an added feature could be to automatically pull the cookies from the Javascript and pump them into the flXHR.swf and forward those along.

Comment by shadedecho — June 25, 2008

@lpeqey – Good stuff. I worked on Flickr’s web-based Uploadr (Flash 9 + JS, now an experimental YUI component), which hits the API with signed calls from Flash. It’s a bit of work to get around the cookie thing if your current implementation uses them, but it’s not all bad.

Comment by Schill — June 25, 2008

Doesn’t Flash incorrectly encrypt all “_” underscore characters in a form POST message body to “%5F” ? This causes issues with a 3rd party application I admin in which the server needs an actual underscore and I cannot add a server side unescape or touch the server side code in any way. Also doesn’t Flash in IE fail to send a value for referrer? Does your flxhr work around these Flash bugs?

Comment by C4 — June 25, 2008

@Schill – I admit I haven’t actually looked into those yet. But they are a great help for you to point out, and I’ll surely do that now. I’m sure that we can find ways to work around them now that we know about them.

Since you obviously have a lot of good knowledge on the topic, would you consider joining the forum over at and entering those as suggestions?

Or better yet, test out flXHR (should be really easy to swap in for your native XHR) and then if you indeed find they are problems, can you enter them as bugs?

As Brian said, I’m passionate about this project and making it the best it can be, and that’s the reason I open-sourced it, so I could get input and help from insightful people such as yourself!

Comment by shadedecho — June 25, 2008

sorry, i mean C4, not Schill :)

Comment by shadedecho — June 25, 2008

My testing seems to indicate this library doesn’t suffer from encoding of _ to %5F. It seems to work nicely. Why not package it as a single .js library and get rid of the dependent files?

Comment by C4 — June 25, 2008

Interesting, in writing Ajax: The Complete Reference ( we utilized Flash a number of times as a binary bridge for doing cross domain requests, addressing storage, or doing push style communications but there are issues to watch out for. As soon as you start poking around XHRs hard you will find first that XHRs themselves are actually inconsistent particularly in method and header support. Flash is worse yet. Just GET and POST and basic stuff you are ok, but beyond that – consider yourself warned. If you think smoke is being blown…take a look at this that just for header change support in XHRs try doing even that in Flash – no dice. I like the idea of multiple communication paths, we even promote falling back to iframes, image-cookie, or Flash as need be. How things are done shouldn’t matter – what is done should. Anyway cool work none the less, but watch the details they can be a bit harder than they look.

Comment by Thomas Powell — June 25, 2008

If that thing will support Multipart data streams in IE i’d definately take a look…

Comment by vsviridov — June 25, 2008

Cookies are kinda hard as you cannot fake them in Javascript with setRequestHeader. If you send a cross-domain request, I suppose you would need the cookies from the other domain, which cannot be retrieved in Javascript.

Comment by Jordan — June 25, 2008

@Thomas-Thanks for your comment. I agree with you that the “devil is in the details”. However, responsible coding can combat that a long way. flXHR probably will perform as well as the skill of the person yielding it, similar to regular XHR. Are there limitations? sure. but what I believe flXHR does which none of the other flash bridges have done before is create a consistent, reliable api for what it *can* do, and hopefully its growing acceptance will help convince Adobe to fix/address some of the bugs their player has, which are definitely the restricting factor to flash bridge technology in most cases, especially flXHR.

But let me be clear… flXHR was designed to replace *all* XHR usage… by enabling a stable, but secure, cross-domain authentication mechanism, I believe it positions itself as better than the IFRAME and script-tag proxying approaches. Only in a very small percentage of cases, where a user has no flash (but does have javascript), which is a small sliver (~1%) that is shrinking daily, would flXHR not perform. It would be up to an author if they wanted to employ an IFRAME or SCRIPT tag fallback for that small use case or not. I don’t think

Comment by shadedecho — June 26, 2008

@vsviridov- very interesting feature request, not one I am much of an expert on. But I can certainly see it being beneficial. Would you consider joining our forum and making it as a suggestion, and we can discuss ways that we could support that? (who knows, maybe it’s already possible and I don’t even know!?)

Comment by shadedecho — June 26, 2008

@Jordan- Yes, cookies are hard to deal with in the Javascript layer. However, I believe (not positive) that theoretically, Javascript could retrieve cookies for the domain the page was on, and pass *those* cookies into flash, which could then create similar cookies (either by headers or by creating a “flash cookie” or by some other means), and try to pass those along with the request, even if it were to target a different domain.

Now, you’re right, the Javascript could not retrieve any cookies for a domain other than the one hosting the page, but then again, the normal XHR couldn’t/wouldn’t pass along those cookies either. The goal for flXHR is to implement as much similar/identical (but improved) behavior to XHR as possible, with a cross-domain capability. In this perspective, I think it’s at least possible we could find a way to do it with the originating (not target) domain cookies.

Comment by shadedecho — June 26, 2008

@C4-Thank you for confirming that the _ encoding problem is not an issue based on your testing. It’s still definitely something to look out for, but it might just be that actionscript’s API’s are improved over the ones you were relying on previously. flXHR uses the “URLRequest” api that AS3 provides, and I would expect it to work properly without side effects, unless there were bugs we needed to identify and then push Adobe to fix.

I have considered creating a singluar JS package once the project moves out of alpha into beta or full release status. However, there are a few issues to consider with this:

1. The .vbs file (for IE binaryResponse emulation only) cannot be packaged with the .js, so that would *have* to be separate anyway…
2. so then we’re talking about checkplayer.js and flensed.js being packaged together. Since checkplayer is really its own standalone project, packaging it inside flXHR.js would mean that it would be tough for an author to upgrade one or the other without upgrading both. Less flexible.
3. The common wisdom has been that packaging together is better because it creates less request/response overhead. But I believe there’s a growing trend to the contrary which points out that single, monolithic file distributions create a different problem, which is that whenever a single piece needs to be updated, the entire big file cache must be discarded. Now, the flensed projects are pretty small, so 20k re-downloaded is not that big of a deal, but as a matter of practice, I believe it’s better to have smaller chunks that can be updated independently.
4. There are other tools out there which can do the packaging and compression for you, but it would be much tougher for a tool to de-compose a file into separate parts and guarantee download re-composition.

As such, I think the most flexible approach for now is to distribute independent files which all load themselves automatically, and when we get to beta and full release stage, provide the compressed distributables for each, and let authors combine them if they really want to.

Comment by shadedecho — June 26, 2008

@c4- oh, and also:

2(b). the code in flensed.js (albeit small) is commonly needed across all the flensed projects (current and future ones), so putting it into the monolithic combined file would actually mean bloating the total download if someone say used 6 different flensed projects on a page. (hey, I can dream, can’t I?) :)

Comment by shadedecho — June 26, 2008

I noticed that one needs Flash 9.0.124 and I have a lower version (9.0.115) and get a JavaScript error in FF 2.0. Give a message and/or give the ability to lower to a lower with version 9.x.

Comment by patitdude — June 26, 2008

I can’t believe people are actually bashing this project, It’s one of the most solid flash/ajax hybrid products I have seen. One thing I am really looking for, however (please link me if such already exists!) is a super-abstracted cross-anything request method.

Such as, if I was to access same-domain it would use XHR (unless XHR was unavailable, falling back to iFrame or related), cross-domain it would use XHR (for Firefox 3), or flash (for others), etc…

Comment by matanlurey — June 26, 2008

@pattidude- flXHR uses the CheckPlayer ( toolset to put the SWF on the page. The CheckPlayer project provides some very useful ways to deal with SWF’s and with plugin versions. Namely, the CheckPlayer object can be set to prompt for an inline auto-update of the user’s flash plugin. flXHR exposes this functionality with a config flag you can pass to its constructor, called “autoUpdate”. If you set autoUpdate to true, and don’t have at least 9.0.124, you’ll be presented with a nice little auto-update message and controls.

Also, the “javascript” error you get is actually intentional… however, the flXHR project allows you to define a “onerror” callback handler, which will give you a nice well-formed error message about the flash version. It only throws a regular javascript error if you don’t define an onerror handler. Otherwise, if you do, you’ll be able to get the error code, and handle the case gracefully (including telling it you want to have the inline-update happen!)

The version choice of 9.0.124 is intentional, and will not be lowered. The reason is that Adobe’s security model for cross domain policies was in flux and not fully implemented/rolled out until this version of the plugin. In addition, there were several other MAJOR security risks that Adobe addressed with that plugin version. For this reason, especially because flXHR crosses a big security line and if used wrongly could expose some really dangerous holes, to give flXHR the most stable and secure delivery, 9.0.124+ will be required. But, the auto-update functionality *should* make it so all your users will be able to automatically get this latest and securest player and then they’ll be able to use your flXHR instance.

Comment by shadedecho — June 26, 2008

Have a look at OpenAjax if you haven’t already:

Comment by shadedecho — June 26, 2008

@patitdude- sorry, my bad, the configuration parameter is called “autoUpdatePlayer”, which you need to set to true. Here’s the full documentation:

Comment by shadedecho — June 27, 2008

FYI… flensed 1.0 (including flensedCore, CheckPlayer, and flXHR) has been released, here:

This project is now fully tested and production ready. In fact, there are a number of enterprise applications already using it.

Comment by shadedecho — December 23, 2008

Another FYI… 4 Major frameworks (jQuery, Dojo, Prototype, and Mootools) now have flXHRproxy plugins to make using flXHR for cross-domain Ajax calls ridiculously easy!

Comment by shadedecho — July 10, 2009

Leave a comment

You must be logged in to post a comment.