IIS7: Differences between static and dynamic content compression

IIS supports two types开发者_Go百科 of compression: static content compression and dynamic content compression. According to applicationHost.config, they are handled by different modules: DynamicCompressionModule (compdyn.dll) and StaticCompressionModule (compstat.dll), and they are configured to compress different types of requests. Also, I’m guessing that the dynamic compression does not cache the compressed requests as opposed the static compression (by default, the compressed files are saved to %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files).

However, besides those obvious differences, I suspect that there is something else. I think that they hook to the IIS pipeline to a slightly different way. Would anybody have an inside into the some more details?

The way I found out was that I was toying with a custom module for modifying CSS files on fly. When the static compression was turned on (and set to handle the default set of files, i.e. also text/css), on cached request my custom module was served the already gzipped content. When I moved text/css to the list of dynamically compressed request, it all started working. But I would like to have a more solid proof that it is really the correct way to do it. Are there some other known consequences / problems?

Update: I think I may have a theory as to why it’s happening. It may not be 100% correct, but it at least it may explain the observed behavior. I think that the static compression module registers itself to the following events (among some others):

RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER

Then when a request for a static file is served, the static compression module in OnMapRequestHandler checks whether the file has been compressed before and whether the actual file has not been changed. If so, it will re-map the request to itself (returning the appropriate redirection using IMapHandlerProvider). When it later actually serves the response in OnExecuteRequestHandler, it sends the compressed file. If, on the other hand, the file has not been compressed before or if it has changed, it does not do the mapping redirect and lets the static content module serve the request and then later in OnPostExecuteRequestHandler compresses the content (and updates its cache). As mentioned above, I'm not saying that this is exactly what's happening (I don't know the source code), it may be only an approximation. Also, the dynamic compression module does not most likely do any of this. It simply compresses the outgoing responses sometimes after RQ_EXECUTE_REQUEST_HANDLER.

Your question is not quite clear, so I will answer a question and hope that it is your question.

The intent of static compression is to compress files that would otherwise be served direct from the hard drive (Css/images/javascript) and as such it compresses each file once and saves the compressed file to disk. This enables very quick very cheap serving of compressed content for static files that change infrequently. It is a pretty safe recommendation to say most website should have static compression enabled.

The intent of dynamic compression is to compress the dynamic responses from ISS modules (asp, asp.net, php, etc.). As this response can be different for each request the compressed output can not be cached. This feature is new from IIS6, though the effect has been achievable in some environments, e.g. by implementing a HttpFilter in ASP.Net. As each request needs to be compressed on the fly this is far more CPU intensive then static compression. So if a server is CPU bound this may not be a good option. Most sites are network and/or database bound so the is often a good idea.

So the dynamic and static refer to the content and effect what strategies can be used.

Some References

• http://www.iis.net/overview/DynamicCachingAndCompression
• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/92f627a8-4ec3-480c-b0be-59a561091597.mspx?mfr=true

Experimenting with IIS compression feature, it appeared to me that dynamic module and static module are not so tied to dynamic or static content (especially for dynamic module).

Activate compression for text/html (or text/*) mime type on dynamic module, and not on static module. Access a .html file. Checks the http response in browser: it is compressed. (Tested on IIS 7.5 on 2008R2 server.)

It appears dynamic compression module is not limited to dynamic content. It does compressed static content providing it matches its mime types list and is not already compressed. So I consider it should be understood as a dynamic "compression module", in the sense it gets triggered on each response (based on its mime type criteria, and on accept-encoding request header).

While the static compression module gets triggered a bit like a background process working on files, and starts serving compressed output only once it has them in its cache. Since static compression module does execute farer in the modules stack, it does handle the response prior to dynamic compression module, and so take precedence over dynamic one if it has compressed output to serve.

So for your specific use case, you should disable static compression module on text/css mime type (beware of removing text\* too if present) in order to avoid caching issues defeating your custom css patching module.

You may in addition activate compression of text/css in dynamic compression module for replacing static compression module on this case. But of course, it will then not leverage the static compression module caching ability.

Unfortunately, I have not found any documentation for backing up above statements.

Another option could be trying to alter IIS module execution order. You would have to remove them all in your site configuration, then re-add them, inserting your custom module maybe before the static compression one. But this could be a tricky path.