A Very Brief History of Internal IIS Compression (from Port80 Software's blog)

  • Comments 1
  • Likes

Port80 Software has started a new blog on IIS topics at

Here's an excerpt from one of their recent posts:

A Very Brief History of Internal IIS Compression

Internal compression in IIS 5 has been plagued by both server-side and client-side bugs.

The server-side bugs that make internal IIS compression unusable in most real-world environments include:

  • The 2048 Bytes bug. (It's misleading because it categorizes it as a browser problem, when in fact it can be corrected on the server, as compression filters do.)
  • and to a lesser degree bugs like the Uppercase Characters bug.

There are also numerous client-side bugs that make internal IIS compression, as it is, practically unusable in most environments. Andy King outlines the nature of these bugs in his short article on HTTP compression.

The root of all of these browser bugs is that browsers sometimes lie; they claim to handle gzip decompression in all cases (in their Accept-Encoding header) when in practice they will choke in a limited number of cases. For example, they will break when trying to decompress a specific file type or--even weirder--they might confuse a specific cached compressed file for a decompressed file and try to render the compressed content. In addition to the longstanding, well-known lying browser bugs, new ones continue to creep up, although they are becoming more and more obscure.

The server-side bugs were fixed in IIS 6. Lying browsers however are still widespread, so the key in implementing compression on IIS 6 is getting a product that includes the browser sensing feature. A product like ZipEnable provides this preconfigured browser sensing that allows IIS 6 compression to work in the real world.

Another impediment to implementing compression on IIS has been an inadequate GUI. The ability to configure at multiple levels becomes crucial with web applications of any complexity. Being able to easily include/exclude specific files, directories and sites oftentimes makes the difference between using/not using compression. The built-in GUI for IIS compression has historically made this so difficult--actually impossible--that the user's only choice was an all or nothing one. Users would often encounter one of these many bugs, then shut off compression and write it off altogether, forfeiting the many benefits that it offers. In short, the combination of server-side bugs, client-side bugs and an inadequate GUI have sabotaged many efforts to implement internal IIS compression. These conditions are what have given rise to third-party compression products like httpZip for IIS 4/5 and ZipEnable for IIS 6.

  • A very nice write-up on IIS Compression