Rare Bug: SWF can’t load XML because of Mod_Deflate - Archives

Rare Bug: SWF can’t load XML because of Mod_Deflate | Archives

January 24, 2012

I recently had a customer complain that our FlashUSAmap was not working on their server. The usmap.swf file was in the same directory as the map.xml file, but the xml file was not loading properly. After much frustration, the customer found the source of the bug. Apache’s Mod_Deflate was compressing the Flash file and preventing it from working properly. This issue only affects servers that have Mod_Deflate enabled. If you are having trouble with your map and need help please contact us for assistance. However, to help anyone who might face a similar issue, Joe Shelton, of Creative Arc (www.creativearc.com), was kind enough to describe the issue and the solution to this problem in greater detail. I am very thankful for his following explanation:

Mod_Deflate is a great bandwidth saving tool that compresses the files served by Apache. But, it continues to cause problems for browsers when dealing with more complex data types, like Flash files. Phil Chen first documented this in 2009 with older versions of Firefox and IE. Since then, the problem has been fixed in those browsers, but re-emerged in Chrome 16.

Phil offers the following Apache configuration code to fix the issue by excluding file types and browsers known to have issues.

<Location>

# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems…
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems

BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don’t compress images and other uncompressible content
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|rar|zip|exe|flv|mov|wma|mp3|avi|swf|mp?g)$ no-gzip
dont-vary
# Make sure proxies don’t deliver the wrong content
Header append Vary User-Agent env=!dont-vary

</Location>

However, the Mod_Deflate documentation itself suggests a Sample Configuration that may be preferable.

AddOutputFilterByType DEFLATE text/html text/plain text/xml

This opt-in scheme will only target the content types you specify. You get the most compression bang-for-your-buck by compressing uncompiled code files, like (X)HTML, CSS, and JavaScript. So, add those content types to the rule, as well, along with any other simple types of data your server commonly transfers.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
text/javascript text/csv

Browsers change, and new file types emerge. The opt-in method protects you from these changes. It probably garners less bandwidth savings than the opt-out method, but also fewer support issues from clients, when their Flash toys end up broken on the odd browser.