Information Gift

AOL vs. Flash

AOL has long presented challenges to web developers. Many of us are aware of munged graphics, designable space and caching issues. We've learned to speak authoritatively to client concerns about same; after all, AOL still commands a user base of 20+ Million dial-up users and a lesser number of broadband subscribers. As marketers or activists, we just can't afford to ignore that many potential visitors.

One AOL issue I keep running across is with Flash content that rely on external images. Developers commonly use external assets for Flash because of the flexibility such an approach allows in managing presentation, be it jpeg imagery, copy, audio/video or other swfs. External jpegs will fail to render for AOL dial-up users unless special precautions are made on your web server.

To explain this, a little background is necessary:

AOL has to manage a massive amount of bandwidth in order to provide their subscribers with a reasonably fast internet experience. One way they do this is via caching servers. These caching servers capture page and image requests and deliver these cached items to AOL users within the AOL network instead of always going back to the source. As AOL's webmaster site states, "If AOL did not use cache technology, a large part of the Internet backbone would need to double or triple in size."

AOL's caching solution is the reason why your client might complain that recent updates to their site do not appear; the client is seeing the older, cached version instead of the new.

Another bandwidth management technique AOL uses is to recompress cached images -- this is where we run into problems with Flash content that use external jpegs. These re-compressed images are not actually jpgs anymore, and as Flash Player is expecting a .jpg file type, presentation will fail.

Luckily, we can fix both caching and re-compression issues with a cache-defeating strategy and a server configuration.

For caching:
If your external content changes frequently or is time-sensitive, you can ensure that the latest version is always retrieved by appending a random number to the url, for instance: myContent.xml?<random_string_here>. Make sure the string is long enough to lessen the likelihood of your users encountering a cached version.

For re-compression:
We can prevent re-compression by forcing the webserver to send .jpg files as a generic binary mime type. AOL's cache will no longer recognize the jpgs as "compressible" and will pass them along unaltered. If you don't have access/control over your server, Adobe has a technote on the re-compresssion issue you can forward to your isp. If you do have access/control, then use the following for your particular server type:

-Apache
You can create a .htaccess file, which is just a text file that Apache recognizes as a kind of configuration command, in your images folder with the following line:

"AddType application/octet-stream .jpg"

Make sure you name the file correctly, that's ".htaccess" ; the preceding period is important and will make the file invisible to Unix-based OSen.

-MS IIS
For IIS you'll need control rather than simple access to the web server.
Open IIS and under Headers/Mime Types set .jpg files to have the mime type "application/octet-stream".

Now that AOL is free to users who bring their own access, there's no reason not to get an AOL account for testing. I also find the AOL client convenient for when I want to test sites outside our network, as you are tunneling through your firewall in order to reach AOL services.

Testers Note:
Unlike the Windows dial-up clients, image recompression is turned off in AOL for Broadband. Testers using that version will need to manually enable image compression in order to test their fixes. AOL for OS X comes with recompression enabled.