IIS支持兩種類型的壓縮：靜態內容壓縮和動態內容壓縮。根據applicationHost.config，它們由不同模塊處理：DynamicCompressionModule（compdyn.dll）和StaticCompressionModule（compstat.dll），它們被配置爲壓縮不同類型的請求。另外，我猜測動態壓縮不會緩存壓縮請求，而不是靜態壓縮（默認情況下，壓縮文件保存爲%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files）。IIS7：靜態和動態內容壓縮之間的區別
但是，除了這些明顯的差異之外，我懷疑還有其他的東西。我認爲他們掛鉤到IIS管道的方式略有不同。有人會有更深入的瞭解嗎？
我發現的方式是I was toying with a custom module for modifying CSS files on fly。當打開靜態壓縮（並設置爲處理默認文件集，即text/css）時，對於緩存的請求，我的自定義模塊被提供給已壓縮的內容。當我將text/css移動到動態壓縮請求列表時，它全部開始工作。但是我想要有一個更堅實的證據來證明這是真正做到這一點的正確方法。還有其他一些已知的後果/問題嗎？
更新：我想我可能有一個理論，爲什麼它的發生。它可能不是100％正確的，但它至少可以解釋觀察到的行爲。我認爲，靜態壓縮模塊將自己註冊爲以下事件（其中一些人）：
RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER
然後，當一個靜態文件的請求提供服務，在OnMapRequestHandler檢查靜態壓縮模塊文件是否已被壓縮之前以及是否實際文件未被更改。如果是這樣，它會將請求重新映射到自身（使用IMapHandlerProvider返回適當的重定向）。當它後來實際服務於OnExecuteRequestHandler中的響應時，它將發送壓縮文件。另一方面，如果該文件之前沒有被壓縮或者如果它已經改變，則它不執行映射重定向並且允許靜態內容模塊服務該請求，並且隨後在OnPostExecuteRequestHandler中壓縮內容（並且更新其緩存） 。如上所述，我並不是說這就是發生了什麼（我不知道源代碼），它可能只是一個近似值。另外，動態壓縮模塊不可能做到這一點。它在RQ_EXECUTE_REQUEST_HANDLER之後有時會壓縮傳出的響應。