There’s a lot of information out there on IIS compression. Especially for what seems like it should be a simple topic…
Here are a few things I haven’t seen collected well in one spot:
1) Don’t test your compression settings from behind ISA. Two reasons: ISA can strip the accept compression header to allow it to inspect content, and some of the default IIS settings are to not compress for web proxies (apparently some web proxies have trouble with compression).
2) There are two sources of troubles with compression:
- Proxies serving compressed content to web browsers that don’t support compression. There are two ways to address this in IIS 6: Either don’t serve compressed content to proxies by setting HcNoCompressionForProxies to true, or else set HcSendCacheHeaders to true and use the default in-the-past HcExpiresHeader & HcCacheControlHeader values so that proxies will consider the file expired and not cache it.
- Web browsers that claim to support compression but don’t support it properly. The most common one still in use is some versions of IIS 6 (see for example http://support.microsoft.com/kb/825057 ). A good list of compression compatability issues is at http://schroepl.net/projekte/mod_gzip/browser.htm . The safest thing to do is to not serve compressed to IE6. Unfortunately, there is no simple way to do this in IIS 6. (the Microsoft Ajax library automatically does this for its files if you use its compression).
3) If you are using Microsoft’s AJAX (ScriptResource.axd) it can do compression separately from IIS, but if you have both do compression you will break things. So either configure IIS to NOT compress AXD and set the scriptResourceHandler enableCompression="true" flag, or else configure IIS to compress AXD and set scriptResourceHandler enableCompression to false. Note that you may have problems with other AXD files depending on what sort of content they produce.