如何防止已经压缩的响应的默认IIS压缩？

Question

TLDR

我有IHttpHandler执行压缩。它本身很好用。但后来我添加了一个IHttpModule，它对那些（和所有其他）响应执行完全不相关的任务，现在IIS正在重新压缩已经压缩的响应。我该如何防止这种情况？

整个故事

我有一个IHttpHandler实现，可以对CSS和JS文件执行组合和压缩（以及其他操作）。 IHttpHandler中的所有内容都与我想要的完全一样。

但后来我添加了一个IHttpModule实现，可以从所有响应中删除不必要的响应标头（Server，X-AspNet-Version等）（包括动态响应）在IHttpHandler事件期间由PreSendRequestHeaders生成的。

但是，似乎只是注册IHttpModule，无论它实际上做什么，都会导致IIS对响应应用压缩，即使响应已经被压缩。

因此，我的IHttpHandler显式压缩响应并设置Content-Encoding标头，然后（当且仅当）IHttpModule也被注册，IIS重新压缩响应（所以有一个浏览器无法读取的双重压缩响应。）

我不想禁用所有默认压缩。我仍然希望压缩视图中的HTML（我希望任何不通过IHttpHandler的CSS和JS也被默认压缩）。

我猜我的问题没有简单的解决办法，因为它似乎是IIS中的一个错误。 IIS不应压缩已经压缩的响应。

我尝试将以下内容添加到我的web.config中，但它没有效果：

<httpCompression>
    <dynamicTypes>
        <add mimeType="text/css" enabled="false" />
        <add mimeType="application/javascript" enabled="false" />
    </dynamicTypes>
</httpCompression>

（根据我对documentation的解释，应该禁用动态生成的CSS和JS的压缩。）

我也试过这个，没有效果：

<httpCompression>
    <dynamicTypes>
        <clear/>
    </dynamicTypes>
    <staticTypes>
        <clear/>
    </staticTypes>
</httpCompression>

（根据我对文档的解释，应禁用所有默认压缩。）

更新

在我的IHttpHandler中，我在最后致电context.Response.Flush。如果我删除此调用，则响应不会被双重压缩。我很好，这是一个解决方案。任何人都可以解释为什么会这样吗？

更新2

我最好的猜测是，调用Flush会将响应置于IIS不认为响应已经被压缩的状态（因此它应用默认压缩）。即使在我的模块中，我也可以检查两个......

• Response.Headers包含Content-Encoding标题和
• Response.Filter不是null，是System.IO.Compression类型之一。

不确定为什么IIS无法确定响应是否已根据这些事实进行压缩。