Abstract: When you have a problem loading an external file through https/ssl in Flex/Flash URLRequest (Flex Error #2118 or #2032) and the problem is Internet Explorer specific, try adding a Pragma: public header.
It is Flash bashing time, so I thought it is a great opportunity to tell you about my day yesterday... and why, yup, flash should die, and if possible drag IE to the grave with it.
Usually we try avoiding Flash as much as possible, a kind of a knee-jerk reaction to anything closed. When we can we send the work to contractors, letting them touch the unclean mess hoping not to catch any germs.
Internet Explorer (be it 6, 7, 8) is a kind of fatality you have to live with. A chronic disease you hope one day they will find a cure for, but you know that for the moment you can just try to manage the pain.
Then there are these moment in life, terrible moments when you have to work with both to resolve some obscure bug.
For one of our projects we have a flash viewer (Flex 3 based) that loads other flash files from the server and shows them.
Everything worked fine until we were asked to pass the whole shebang to HTTPS. Firefox, Safari, Opera and chrome Continued to work without a glitch. But on IE, nothing happened.
Now, none of the guys here really has a Windows box for development. We just have a stack of older notebooks with different versions of explorer and you just take one from the stack when you need to start debugging (mostly everyone also has some VMs for IE debugging, but then again it does bog done your machine); So this was a problem because we could not use the integrated Eclipse Flex 3 debugger which allows for remote debugging ... when the server is remote, not with a remote browser (and if it does allow that, I have strictly no idea on how to set it up).
So first we installed the debug version of the flash plugin to see if there were any exceptions... an generally what was happening.
yippy. We got an #2118 IoError. So clearly the problem was somewhere around making the call to fetch the distant SWF file. This already permitted us to find some ugliness in the code.
This is somewhat evil:
private function ioErrorHandler(event:IOErrorEvent):void
{loader.contentLoaderInfo.dispatchEvent(new IOErrorEvent(IOErrorEvent.IO_ERROR));
}
As it creates a new exception loosing the original information. Much better:
private function ioErrorHandler(event:IOErrorEvent):void
{loader.contentLoaderInfo.dispatchEvent(event);
}
But this was not as easy as that... no sir. It took several hours just to get Flex Builder to behave somewhat like and IDE. I could not list all of the weirdness.. line numbers that display but do not scroll with the code. Having to click twice on the debug button. Once to let the flash plugin explode, the next time to have it run. Weirdest implementation of Locale you can imagine. And yes merging files that are half code half XML...
Still, now we had something that showed a more sensible exception....hello Mr. Error #2032: Stream Error.
A quick google search brought up a bunch of sites talking about IE only problems with this error. We were on the right track. And much to our surprise discovered the solution was not on the flash side but on the server, as this was truly an IE issue. Different sites proposed different recipes. We didn't test them all but it boils down to having the script serving the content over ssl add a header.
Pragma: public
and if ever using cache control headers:
Cache-Control: no-store
Earlier we discovered that with IE8 serving the incorrect content-type header (or not serving one at all) also resolved the issue (why? why? why?)
What is the useful semantic of that? Why is this needed? I don't really want to discover; Is this really an IE issue or a Flash/IE integration or ... couldn't care less, it works. Pain managed.
So basically this is a one liner correction. For a bug that should never have existed. And maybe this is not a Flash bug, but the tools to debug this thing are so incredibly horrible that this very very simple task, took a day of my life.
From my reading it seems the same bug appears not only with ssl connections but also when the content is Gzipped, it seems the same solution applies.
Thanks for your help Ori yesterday !
Laisser une réponse