Flash Player Bug with RoR 2:HTTPService fires fault by http status code 201

Regarding Flexible Rails: Flex 3 on Rails 2, by Peter Armstring, and its Forum

This relates to a previous thread, but the solution is buried deep within the thread. There is a bug in Flash Player, which has been reported:


Adobe considers this bug report “closed” with the “resolution” of “cannot fix”. Basically, Flash Player HTTPService incorrectly faults on status code 201, which indicates “successful creation”. The Rails 2 scaffolding code returns this status code 201 on successful creation, triggering the fault event from HTTPService, and preventing the code in CreateLocationCommand.as on page 318 (for example) from working.

Since Adobe has given up on fixing this error, a workaround is required. One workaround would be to intercept the fault event, locate the status code 201, and treat it as “success”. However, I cannot find the status code in the fault event (!). You could also just treat the fault as a “success”, but then you wouldn’t know whether the create was successful.

The best workaround seems to be to change the status code returned from 201 to 200. This can be done in the rails controller. In this case, using iteration 8 code, pomodo/app/controllers/locations_controller.rb, line 55, change “:created” to “:ok” and CreateLocationCommand.as will work again.

James Nachbar

Flex-Rails:protect_from_forgery problem with Rails 2.1 produces ioError 2032

Update for Rails 2.2: According to the release notes: “Request forgery protection has been tightened up to apply to HTML-formatted content requests only” in Rails 2.2 — I have not tested this, but it should obviate the problem addressed in this post for Rails 2.2 and newer.

Regarding Flexible Rails: Flex 3 on Rails 2, by Peter Armstrong:

The book talks about commenting out protect_from_forgery, and then uncommenting it in iteration 5 without mentioning what had changed to allow protect_from_forgery to be used.

In reviewing old vs. new rails code (particularly vendor/rails/actionpack/lib/action_controller/request_forgery_protection.rb), it appears that the older versions of rails did not run the forgery protection check for .xml requests, but the newer versions do. Thus, unless you are manually adding the appropriate parameters (see the above file for the current test being done to see if the form request is forged), you will fail the forgery test unless you prevent the test from running. More info on that here:


at a minimum you will need:
skip_before_filter :verify_authenticity_token
in your sessions_controller.rb to avoid the ioError 2032.

You can track this error down by adding a fault event handler to the HTTPService (e.g. in LoginBox.mxml on page 153). You can also look at the output from the server (the “ruby scriptserver” command) which will show status code 422 instead of 200 for the “session.xml” request.

For a more detailed look, go to the rails log at logdevelopment.log and look at the end for the most recent error. It will show that ActionController::InvalidAuthenticityToken was thrown by /vendor/rails/actionpack/lib/action_controller/request_forgery_protection.rb:86:in `verify_authenticity_token’

CSRF attacks are not so relevant for applications running within Flash Player (as opposed to, for example, applications running within a browser), since Flash Player won’t go from one site to another.

If you want to continue to use forgery protection for the .html requests, the best solution is to

1) uncomment protect_from_forgery (so the protection token is generated),

2) skip_before_filter :verify_authenticity_token in the controllers that need to allow .xml to be served without the forgery protection, and then

3) call “verify_authenticity_token” (the same call used by request_forgery_protection.rb) within the .html generation code that you want to protect. verify_authenticity_token will throw the InvalidAuthenticityToken exception if the token is not correct.

If you want to protect your .xml calls too, the check within verify_authenticity_token is:
form_authenticity_token == params[request_forgery_protection_token]
so you would need to get your rails app to send the form_authenticity_token to the Flex client when the session is created, and then your subsequent calls will need to set the “request_forgery_protection_token” param.

James Nachbar

Flex-Rails: Non-Debug Flash Player caches, so fails to update list – status code 304

Regrading Flex/Ruby on Rails Programming:

And then just when everything was working in the debug Flash Player, I decided to fire-up IE & run the application in Flash Player in non-debug mode, and it stopped working: after creating an item, the list blanked out rather than being updated.

Ultimately, the problem was that, in non-debug mode, using IE (but apparently not Firefox), Flash issued a “conditional get”, and was getting a 304 “not modified” response instead of the updated data. In debug mode, Flash was issuing a regular GET, and thus got the correct info. Thus, the application worked in debug mode, but not in non-debug mode.

I have seen that RoR 2.1 included some new caching functionality, although I don’t know if this is the kind of caching they are talking about, or why rails was reporting “not modified” even after the database upon which the response was based had been modified..

That Rails was returning status code 304 could be seen in the server window (“ruby scriptserver”)

For some reason, even though I am creating a new HTTPService object for each call, the return from the POST (i.e., the one object being created) was still being returned in the result event when I sent a GET to obtain the entire list. I could determine that by sending the result event info from the list command to the debug window:

var x:XMLList = XMLList(event.result.children());

Even though this was the result of the GET call, I was still getting the result of the POST.

My fix (actually more of a workaround) was to add a time-generated string (“?” + Number(new Date()) ) to the end of the request URI, thus avoiding the caching problem. A better solution might be to send a “no-cache” header from the RoR portion, although I have not tested that. More on avoiding caching here:


More evil IE caching, I guess!

James Nachbar