The referenced resource does not exist or the swf is trying to access a file across a restricted domain.

This error causes Flex to report a fault error on the request even though it was successful. The 201 status code is handled fine in all other browsers except IE (6 & 7). I did some research on the issue thinking it must be something easy to fix, that many others have run across before me. It seems the error is out there for lots of different reasons.

One post reported that IE was having a caching issues, and the way to solve it was to add a random number on the end of your service calls or you have to set the response headers in your server side page to prevent caching. This one sounds similar to a FireFox issue I ran into a couple years back, but didn’t effect the results:

http://www.judahfrangipane.com/blog/?p=87

The overwhelming number of posts on the subject suggested that Rails and Adobe both share the responsibility for this error (depending on if you are a Rails dev or a Flex dev, the debate rages as to who is to blame). The fix seems to be changing status returned from Rails to something other than 201. This seems to be the legit solution since the web service I was hitting is running Rails:

http://stackoverflow.com/questions/354936/flex-2032-stream-error-in-ie-only
http://nachbar.name/blog/2008/06/14/flex-railsprotect_from_forgery-problem-with-rails-21-produces-ioerror-2032/
http://onrails.org/articles/2008/02/20/dealing-with-http-errors-in-a-flex-with-rails-application
http://www.manning-sandbox.com/message.jspa?messageID=64372
http://nachbar.name/blog/tag/adobe-flex-programming/

If you think Adobe should fix the issue (as some Rails people protest) then you can view all the other bug reports Adobe already had lined up to fix that involve a 2032 Stream Error, just type in Explorer 2032 and you will find them:

http://bugs.adobe.com/jira/secure/QuickSearch.jspa

The workaround we ended up implemented was totally client based. In the fault handler of this particular service request, I look for the errorID value of the Fault event and ignore it. It was all I could do on short notice and I wasn’t about to convince the backend dudes that we needed to change the server response from 201 to 200, pick your battles and my first battle was to get this app into the war.

For me the real culprit is IE (easy target). Something that works in every other browser but IE is so friggen familiar to anyone who has done any cross-browser work. IE sucks, it has always sucked, and it will always suck, period. My other thought is about web services and codes in general. As an application developer, I use a lot of different services, consuming data from many different pipes. I couldn’t tell you as a consumer of web services and an application designer what the value of having a returned Status of 201 has over returning a Status of 200, can you? I make a request, and if the request is good, just tell me ok, I don’t need to know that the server returned a HTTP Status Code of 311 (the server code for “I just made you a sandwich”). I need to know only two basic things, was the request good, or did it explode?

I think some API dudes and backend dudes are purists, they want server codes to bubble up to the client so we can admire them, even though in practice (meaning you actually build applications with these services) you don’t really need the extra data. Hey, I am totally used to having to make 5 service calls to accomplish one thing with a web service, I would never ask for the service to be changed to convenience the client, but some information is superfluous and could be scaled down.

UPDATE

Saw another blog post about the same topic at UserFlex.

- Mister