We got this nice response to a blog post recently with a grand question:
before i started using ZipEnable on my company's server we used a bit of free .NET code (available at the URL below). It is designed to compress the output of .NET sites (doesn't do anything for our ASP or PHP code). our sites that use the code and are ZipEnabled seem to go at great speed but i'm wondering... now that we've got ZipEnable should I remove the HTTP Compression code or do they work together?
http://www.blowery.org/code/HttpCompressionModule.html
PS: here's one of the sites where both ZipEnable and the HTTP Compression Code Module is used: http://www.motoretta.ca
We took a look the site our blog respondee (and gracious customer!) mentioned above and, by all appearances, everything is functioning correctly. Double HTTP compression is most certainly not being applied to his Web server responses -- that would not be a good thing. However, it would be very obvious if that was occurring.
Both compression tools (meaning 1. IIS 6.0 native, core Web server code-integrated, HTTP compression managed by ZipEnable AND 2. the .Net module compression approach) can co-exist on the same server nicely -- if they were configured to stay out of each other's way. Or, if you don't notice any issues!
In fact, there are some scenarios where someone might want to run both types of tools. For example, if you wanted to take advantage of the advanced .NET partial page caching features, you could use the compression module for your .aspx pages, caching the page fragments as needed. All other compressible files, such as CSS and JavaScript, could be mapped through ZipEnable so that the native IIS compression compresses those. The disadvantage in this case is that pages compressed by the .Net module do not benefit from the browser compatibility checking feature that is part of ZipEnable -- the only solution for this major compression challenge with IIS 6.0 built-in compression...
Since both tools apply compression, if you don't do any .aspx page fragment caching, you might want to to keep things simple with ZipEnable, browser safety and IIS 6.0 native compression zapping those gzipped pages out to your Web users...
Cheers!