HTTP Status 201 causing Flex #2032 Error in IE only

I ran into a problem right when we were going to launch a new Flex web-based application to production (of course) with Internet Explorer and Flex. I was calling an RESTful service that returns XML and using the built-in Flex HTTPService with either POST/GET as the method for the request. Most of the service calls either return a HTTP Status Code of 200 (OK) or they throw an error. For one POST request that returned a HTTP Status of “201 Created” Flex threw up a 2032 Stream Error in response. Here is a brief definition of the error:

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:

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:

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:

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.


Saw another blog post about the same topic at UserFlex.

– Mister


  1. I cannot agree with you here, you do care about the HTTP Status being returned from the server as it’s not just the ambiguous “I can’t load the resource” stuff that you are interested in.
    E.g. a 404 indicates that resource is unavailable a 302 indicates the alternate source to the resource

    1. @Pratyoosh Sharma, You can make a good argument for 404 or 302, but the difference between a 201 and 200 is really the question, what advantage does it have for clients to know that a 201 happened as opposed to a 200? If you look at other API’s (Flickr, Yammer), you won’t find a 201 returned status.

  2. Ran into the same problem here today. Though it would be easy for me to just change the response to a 200, I think it is not the best solution. You could argue there is no difference between 200 (OK) and 201 (Created), since the latter one only makes sense when creating some entity. However, there is a big difference between a 200 and a 202 (Accepted), if you want to indicate the request is being carried out instead of successful right away.
    Furthermore, since there is a lot of interesting development going on in the REST frameworks area, we could use some best practices on the client side.
    So, instead of calling the API guys purists, maybe we should try and stick to the standards that are in place and simply check for a HTTP status response. That way, the client side works as supposed, you can take appropriate actions and you can use whatever framework on the server side.

  3. I have been searching on net for this issue and I ended up getting information like check URL, crossdomain.xml, response size etc. None of them were making logic in my specific case. Eventually I found this post and all I can say is – Thanks Mister! I got the answer that would possibly close to answering my issue.

Comments are closed.