IIS supports two types 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](https://stackoverflow.com/questions/5609479/custom-iis-module-conflicting-with-gzip). 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](http://msdn.microsoft.com/en-us/library/ms693056%28v=VS.90%29.aspx) 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](http://msdn.microsoft.com/en-us/library/ms692607.aspx)). When it later actually serves the response in [OnExecuteRequestHandler](http://msdn.microsoft.com/en-us/library/ms691104%28VS.90%29.aspx), 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](http://msdn.microsoft.com/en-us/library/ms693033%28VS.90%29.aspx) 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.