This post was written by jimrobson on August 30, 2008
Posted Under: Alfresco, Browsers, Flash, Flex

Don’t you love acronyms? I probably could have come up with a more descriptive title for this post, but the acronyms were just too much fun to resist. The disadvantage is that the title probably leaves you wondering what this post is actually about. Well, I’ll tell you. It’s about issues that Internet Explorer has in dealing with certain kinds of files - specifically, any kind of file that IE passes on to an ActiveX control - over HTTPS. Examples of files that leverage ActiveX in IE include MS Office files and, tragically, Adobe Flash files (SWFs). Check out Microsoft’s tech note on the subject for more details of this feature (MS insists that it is not a bug).

No Internet Explorer!

This week my team put the first iteration of our custom Flex-on-Alfresco application on the internal QA server. Unlike our Dev servers, which use HTTP, the QA server uses HTTPS. This didn’t cause any issue in Firefox or Safari, but on IE the QA testers were unable to log in to our application. When we looked into it, we found that the Alfresco Flex SDK was throwing an error of type ApplicationError - which basically means that something went wrong in the request/response loop. The stack trace was similarly unhelpful.

When we analyzed the communication using Charles, we could see that the server was indeed sending back a valid response. So if the server was sending back a valid response, why did the Flex application keep telling us that it wasn’t getting the response? I had my own suspicion, and it was confirmed when I analyzed the response headers using Live HTTP Headers.

The reason for the failure is that, by default, Alfresco’s HTTP/HTTPS response headers use the “no-cache” setting, which is one of the settings that causes IE to fail. Essentially, IE needs to put the file in its cache in order to hand it off to the ActiveX control (in this case, the Flash Player). Since IE received the “no-cache” instruction, it couldn’t put the file in its cache, so it had nothing to hand off to the ActiveX control but an error message. As it turns out, we had coded our Flex UI in such a way that we would not let people access the application unless we got a valid response to our login request. Call us sticks-in-the-mud if you like, but we are not budging.

Alfresco is not the only server technology that puts in IE-killing headers by default. As you can read in this flexcoders post, Spring defaults to similar settings. In fact, this is not an unusual problem for applications that need to run over HTTPS; after all, if you are building a dynamic application that is designed to serve truly fresh (if not real-time) data, then it seems to be common sense to tell the browser not to cache pages. However, no one ever accused IE of running on common sense.

How do you diagnose this issue? As mentioned above, the Alfresco Flex SDK gave us the generic AppicationError message. When using straight HTTPService calls, you are likely to get “Error #2032: Stream Error” or simply “HTTPError” - which are similarly unhelpful. The clearest way I have found to diagnose this particular issue is to run Live HTTP Headers, which will tell you immediately what the response’s caching instructions are. If you are experiencing an IE-only problem over HTTPS and your server response header says “no-cache”, then you know why your Flash or Flex or other ActiveX application is bombing.

Solution: We decided to turn off the no-cache settings at the server (Apache) level in order to allow QA testing to go forward, and that did the trick. However, before we go live we may decide to alter the settings programmatically in Alfresco, and this document appears to describe how it is done. If you are working in Spring, you might find the aforementioned flexcoders post helpful. If you are uncertain as to which caching instructions to put in your headers, this blog post by Marc Speck of Switzerland includes a helpful list of the HTTPS cache settings that do and do not work with ActiveX in IE.

Reader Comments

Ugh, Jim, I remember this “feature” we had to workaround back on PW. Hopefully you recognized the problem quickly this time thanks to that experience.

Written By Chris Murphy on August 31st, 2008 @ 10:20 am


Yes, the PW experience proved invaluable here; in fact, as I recall, you’re the one who introduced me to Live HTTP Headers!

Written By jimrobson on August 31st, 2008 @ 8:03 pm

Thanks for this blog, really help me due. :)

PHP inject ‘Pragma’ and ‘Cache-Control’ on the session_start(); function by default.

To remove it, at easy way with
after the session_start();

Written By i0n on October 7th, 2008 @ 6:13 pm

I really need that data is not stored in the browser cache, solution above is not good.

Written By wilcap on December 2nd, 2008 @ 12:00 pm

@wilcap: If you review Mark Speck’s post referenced in my post above, and/or if you research the possible cache settings a little, I think you will find that you can prevent IE from caching data and still allow it to run the SWF.

Written By jimrobson on December 2nd, 2008 @ 12:34 pm

I’m using OpenX to serve ads on a Flex 3 website. It works fine in Safari and Firefox, but I get error #1090, an xml parser error, when viewing the site in IE8. The xml is fine.

I’m using http not https. Could the 1090 error be due to the problem you outlined in your post? Has anyone encountered a similar problem? I’ve been tryin to solve this nasty bug for weeks without any luck. Any advice would be most appreciated.


Written By Chris on May 11th, 2010 @ 1:08 pm