Pitfalls of loading Flex modules

I’ve just run into two issues for Flex module loading. Maybe it helps somebody…

Hungry garbage collector

When loading modules, it’s important that you keep a reference to the IModuleInfo instance. I did store them in a Vector and thought everything works that way. What I forgot was a subtle timing issue: I checked the Vector for loaded modules after I pushed a new loading job into Vector. So it could happen that right after pushing the job into Vector, it got thrown into the garbage.

Stale Expires HTTP headers

Another nice one are HTTP caching headers: By mistake, I assigned all Flex modules a fixed Expires HTTP header. It expired this morning and loading modules became a seemly random process: The first module loaded successfully, but the second and third failed. When the same Flash Player instance loaded the module a second time, everything worked well. Well, after some debugging, I found the culprit in the HTTP header. After removing the Expires header, everything runs smoothly again.

Let me know if you have other stories about module loading.

IE7 + SSL + XML? = Flex “Error #2032: Stream Error”

I’m developing a Flex application that runs smoothly in Firefox over SSL. Today, I just wanted to verify whether Internet Explorer 7 (IE7) hosts the application as nicely. Somehow, I wasn’t surprised that the Microsoft browser invoked an “Error #2032: Stream Error”.

Don’t assume, test!

Searching brought me to judah’s blog, but the blog is only about URL paths. Because the application runs in Firefox and in non-SSL mode in IE7, this was not causing my problem. However, some comments on judad’s blog and on this blog were interesting: An Adobe TechNote warns of this issue. However, the note was last updated in 2005 what meant that it could not relate to IE7. I also found a Microsoft bug report describing the issue but it only links the bug to IE5 and below. The assumption that Microsoft has corrected this bug since 2005 was probably my biggest mistake in this hole story.

The search could go on. Barton has some nice input and proposes to tamper the HTTP header: remove Pragma and set Cache-Control: no-store. So I did and checked the HTTP headers in the SSL connection with Wireshark (which is also quite bogus for decrypting SSL packets, at least 1.0.0). This made the whole thing running. And in details:

Works:

1. Cache-Control: no-store
2. Cache-Control: no-store, must-revalidate
3. Cache-Control: no-store,max-age=0,must-revalidate
4. Cache-Control: max-age=0,must-revalidate
5. Cache-Control: must-revalidate

Does not work:

1. Pragma: no-cache <+whatever header like Cache-control: no-store>
2. Cache-control: no-cache
3. Cache-control: no-cache, must-revalidate
4. Cache-control: no-cache,<+whatever>
5. <empty = no Cache-control at all>

Controlling Cache-Control

In Firefox, you can check the content of the cache by entering about:cache in the URL. You will notice that Firefox caches all data coming from an SSL connection in memory. Hence, closing a tab does not delete the data but a restart of Firefox does.

IE7 caches data coming from SSL normally to the disk. The HTTP header Cache-Control: no-store prevents this default behaviour. Unfortunately, I don’t know a similar command like about:cache in IE7, so haven’t investigated the exact caching behaviour. Cache stored on the disk can be checked with “Tools menu > Internet Options > General Tab > Browsing History section > Settings Button >View Files button” but I don’t know how to see the cache in the memory.