HTTP Response Compression in a URL rewrite enabled IIS installation

HTTP Response Compression
in a URL rewrite enabled IIS installation

It is normally a good and recommended practice to enable HTTP Response Compression regardless of the server you use to host a site. Response Compression uses the available bandwidth more efficiently thus providing faster transmission
times between compression-enabled browsers and the server. This, of course, means faster loading pages for the end user as well.
HTTP Compression in IIS 6.0 is pretty easy to set up. You can click here
for detailed instructions on how to do it.

I would like to note that IIS compression isn't perfect. I did see a case where it failed and it turned out to be because the content was not actually being served by the IIS instance, but it was being redirected to a Tomcat server which processed all the requests
and sent them back to IIS.

This routing is achieved by using a Rewrite Engine Software—ISAPI Rewrite. There is one additional feature that is obtained by using this rewrite software and that is providing more relevant-looking links (sometimes known as
short or fancy URL's) to the end user.

You may wonder why someone would ever use such a server configuration. There are many good reasons to do it; unfortunately they are out of the scope of this blog.

However, if you ever run into a similar situation, I suggest you keep reading this blog. It may save you some time in setting your Response Compression to work appropriately.

Compression Tools

There are a lot of third party tools you can use for Response Compression in IIS like:

httpZip,
XCompress,
Helicon Jet, etc. Most of them are implemented as an ISAPI filter you can add to IIS and use with no trouble at all.

I decided to use Helicon Jet as our compression tool. Installation is really simple, just download and run

HeliconJet.msi. After installation completes you will find a Helicon Jet Tab under site properties in the IIS console.

Helicon Jet is configured separately for every web site in IIS. Its settings are accessible through IIS console snap-in extension among the other web site properties. You can access the console by opening a run window from the start menu and typing
inetmgr.

Helicon Jet comes pre-configured for the most system configurations so you may start using compression immediately after enabling it. When you click on the Enable button the '/' entry will be automatically added to the Directory (URL) pattern list, which will
enable compression on entire web site. By default compression is enabled for both static and dynamic content, but server side caching is enabled only for static content and compression level for dynamic content is lower.

There are a lot of options you can set in the Helicon Jet properties tab. Helicon Jet is configured on three different levels:

Directory & file level configuration
File extension & MIME type level configuration
User agents level configuration

I recommend that you take a look at the documentation that comes along with the product to find out what the different options are best used for. However, I suggest enabling file compression for the following file types:

Static Content

HTML Pages (.html)
Cascading Style Sheets (.css)
Java Script Code (.js)
HTML Components (.htc)
Portable Document Format (.pdf)

Dynamic Content

ASP Pages (.asp)
ASPX Pages (.aspx)
ASMX Pages (.asmx)
Dynamic Link Libraries (.dll)
Executable files (.exe)
PHP Pages (.php)

Below is a table with some data that I obtained by running tests on our site.

A tool called Fiddler was used to monitor and see the HTTP requests and responses.

File	Compression Disabled [bytes]	Compression Enabled [bytes]	Compression Ratio [%]
home.html	18,512	3,478	81.2
query.js	197,156	54,034	72.6
global.css	76,640	15,184	80.2
global.js	37,256	10,430	72.0

That is it for now. In the next blog I will address the issue of connecting IIS with Tomcat using an Apache proprietary protocol called AJP13 instead of HTTP.