httpZip for IIS compression is one of our most popular Microsoft IIS Web server tools, and many folks like the dynamic file compression cache, though sometimes it is misunderstood a bit...
Unrelated to a proxy or browser cache, httpZip’s cache will store a compressed version of the resource once it has been requested (if httpZip caching is enabled). This is good news for static files like HTML, CSS, JavaScript, XML, etc., as you only pay CPU-wise to compress the response once on the first request; subsequent requests will be served from the cache (unless the file is modified on disk or there is an overriding expiry-based cache control header that comes into play).
For dynamic files, you have to test this compression caching functionality with your ASP, ASP.NET, PHP, ColdFusion, JSP, etc output. Think of this feature as an alternative to pre-generation of basically unchanging dynamic content. If the content changes only based on changes in the query string and/or the value of a cookie, it can be compressed and then cached by httpZip, which avoids a return trip to the application server and avoid recompression on later requests.
So, what may seem complex with httpZip dynamic compression caching is actually very simple.
> Given the URL and page example below:
http://host/page.asp
httpZip (with dynamic caching on) can cache the file in compressed format after the first request for faster serving on subsequent requests.
> If there are multiple versions of the page based on query strings, httpZip can cache each one:
http://host/page.asp?id=1
http://host/page.asp?id=2
http://host/page.asp?id=3
> Also, you can feed httpZip’s compression cache a cookie name for dynamic caching:
Cookie=FOO
So, for every page with a different cookie that has a different value per user, you will get a cached compressed page:
FOO=292309032930
FOO=213920390293
FOO=2039209302
Basically, this is a good practice for pages that are dynamic but don't change in a frequent or unscheduled way from the database once created. Where you can get into trouble is a dynamic file that does change based on the database and is user-specific (a customer record updated by multiple users, a home page customized for the user based on a login that does not have unique query string or cookie value, the list is infinite…). The main idea is not necessarily that database changes won't happen, but that such changes (like those made using an admin form or something) must at least be infrequent and regular enough that the necessary updating of the httpZip cache can happen by means of cache control headers. Essentially, the cache control headers play the same role here that a scheduled run of a developer's "publish-to-static" script would. Of course, if the pages really don't ever change, so much the better -- then there's no more need to use the Expires headers than there would be to rerun the publish-to-static script.
Extra credit: An implication of this is that you would want to use Expires headers with fixed expiry dates, rather than the cache-control header with the max-age=some-number-of-seconds directive.
So, make sure to check out dynamic compression caching in httpZip. You will find this is a feature that most origin server compression utilities do not provide -- and you cannot use IIS 6 native compression out of the box to accomplish this task either (though, with some coding, you could put the compressed resource in the ASP.NET cache, if you use that app server, etc). The benefit is faster dynamic pages, less bandwidth used to serve the app, more throughput and availability. Sounds good to us.
- Port80