Question

I am using the Django GZip middleware (django.middleware.gzip.GZipMiddleware) to compress content if the browser allows compression.

If the browser is Internet Explorer (MSIE) and the content is a Javascript file, then the middleware does not gzip the content. My understanding is that the middleware avoids compressing in this case because IE6 (without patches) has issues with gzipped responses.

For our site, we do not support IE6, but we do support IE7 and IE8. Considering that we do not support IE6, would it be best practice for us to gzip all javascript files even if the browser is IE?

If so, what is the best approach for getting these files gzipped? We would like to continue to use a Django middleware module for gzip. Should we make a copy of the gzip middleware module and edit the few lines that deal with IE and Javascript (this feels like we would be violating DRY)? Using Apache for gzip is also an option.

Answer 1

Versions of IE6 that are affected by problems with gzip on JS/CSS are no longer in common circulation (and were a minority case even at the time). And Netscape 4 is long, long gone.

For this reason I would strongly recommend removing all extant User-Agent-sniffing gzip hacks. Send compressed HTML/JS/CSS to all browsers that request it (with Accept-Encoding), as per standard HTTP/1.1.

if "msie" in request.META.get('HTTP_USER_AGENT', '').lower():

Oh dear. That’s a really poor test even by UA-sniffing’s dismal standards. No checking that it’s actually MSIE in the right place in the string (as opposed to anywhere in all the trailing bits; easy to get false positives), and it doesn’t check for SV1 which was traditional for the gzip test (as IE6SP2+ versions cannot be affected by the bug), so it breaks compression for all IE which is just unnecessary.

It also doesn’t set Vary: User-Agent, so proxies will cache the wrong version. And it sets Vary: Accept-Encoding for IE when not using Content-Encoding, so it’ll break cacheing in IE.

Should we make a copy of the gzip middleware module and edit the few lines that deal with IE and Javascript (this feels like we would be violating DRY)?

You could, and maybe submit the patch to Django. Because their current approach is IMO simply broken.

Using Apache for gzip is also an option.

Yes, if you’ve got Apache upstream definitely use that (eg. with mod_deflate). It’s most efficient if you can use it to serve static files like scripts too. (Try to keep your JS in static scripts rather than generating/templating on-the-fly.)

Again, don’t use the browser-sniffing rules mentioned on the mod_deflate page. They’re fragile and ugly, and are trying to code around a Netscape problem that has affected no-one in the last decade.