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.
SetOutputFilter DEFLATE
# Netscape 4.x has some problems…
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
# 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
However, the Mod_Deflate documentation itself suggests a Sample
Configuration that may be preferable.
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.
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.