I have been following Scott Forsyth's instructions on how to configure HTTP compression in IIS 6.0. Despite following it to the letter, I did not receive any response that had a Gzip or Deflate encoding - Fiddler still showed them uncompressed. Neither was there anything in the Temporary Compressed Files directory. I did not see anything out of the ordinary, and it wasn't until coming across Jeff Atwood's experience did I realise the significance of the third node <IIsCompressionSchemes>
<IIsCompressionSchemes Location ="/LM/W3SVC/Filters/Compression/Parameters"
HcCacheControlHeader="max-age=86400"
HcCompressionBufferSize="8192"
HcCompressionDirectory="G:\IIS Temporary Compression"
HcDoDiskSpaceLimiting="TRUE"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcExpiresHeader="Wed, 01 Jan 1997 12:00:00 GMT"
HcFilesDeletedPerDiskFree="256"
HcIoBufferSize="8192"
HcMaxDiskSpaceUsage="1073741824"
HcMaxQueueLength="1000"
HcMinFileSizeForComp="1"
HcNoCompressionForHttp10="TRUE"
HcNoCompressionForProxies="TRUE"
HcNoCompressionForRange="FALSE"
HcSendCacheHeaders="FALSE"
>
</IIsCompressionSchemes>
I was testing from my home desktop workstation to my home server. They are both in the same network, but I was using an FQDN to access my server. That meant I was throwing the request out to my ISP's proxy server before it roundabouts back to into my house. This explicit proxy server appears to be a rather old implementation that hasn't changed over the years. Despite my browser set to use HTTP 1.1, the proxy makes a request to my server using HTTP 1.0. If I set both HcNoCompressionForProxies and HcNoCompressionForHttp10 to FALSE, it would send the encoding intelligible to the proxy, which in turns returns me garbage in the browser.
By giving up on this old proxy and utilising the ISP transparent proxy, I was able to connect at my server endpoint with HTTP 1.1 and finally getting to enjoy savings in traffic load (not this website unfortunately). An average of 3-5 times smaller is what Fiddler tells me. I am taking it that HTTP 1.0 connections should not be served with compression as results at the client end is unpredictable. So HcNoCompressionForHttp10 ought to remain TRUE.
Also of useful note is that few compress javascript and CSS files. In the age of Web 2.0 I think it is a good idea to start squeezing these increasingly bloated members too.
<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/deflate"
HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
HcCreateFlags="0"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="9"
HcFileExtensions="htm
html
txt
css
js"
HcOnDemandCompLevel="10"
HcPriority="1"
HcScriptFileExtensions="asp
dll
exe
aspx
asmx"
>
</IIsCompressionScheme>
<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/gzip"
HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
HcCreateFlags="1"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="9"
HcFileExtensions="htm
html
txt
css
js"
HcOnDemandCompLevel="10"
HcPriority="1"
HcScriptFileExtensions="asp
dll
exe
aspx
asmx"
>
</IIsCompressionScheme>
UPDATE: I have removed axd from the HcScriptFileExtensions list, because I found that as resource handlers, .axd requests do not always return compression-friendly content especially those developed by third-party component vendors. This has resulted in odd and unpredictable behaviour of controls that make extensive use of axd resources.