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

Leave a Reply

Your email address will not be published. Required fields are marked *