IE, SSL, XML, HTTPS, SWF & DOA
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).
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.
