How do I prevent default IIS compression on a response that is already compressed?

Question

TLDR

I have an IHttpHandler that performs compression. It works fine on its own. But then I added an IHttpModule that performs a completely unrelated task on those (and all other) responses, and now IIS is re-compressing the already-compressed responses. How can I prevent this?

The Whole Story

I have an IHttpHandler implementation that performs combination and compression (among other things) for CSS and JS files. Everything in the IHttpHandler works exactly like I want it to.

But then I added an IHttpModule implementation that removes unnecessary response headers (Server, X-AspNet-Version, etc.) from all responses (including the dynamic responses that are generated by the IHttpHandler) during the PreSendRequestHeaders event.

However, it seems that simply registering an IHttpModule, regardless of what it actually does, causes IIS to apply compression to the response, even if the response is already compressed.

So, my IHttpHandler explicitly compresses the response and sets the Content-Encoding header, then (if and only if) the IHttpModule is also registered, IIS re-compresses the response (so there's a doubly-compressed response that browsers can't read).

I don't want to disable all default compression. I still want HTML from views to be compressed (and I want any CSS and JS that doesn't go through the IHttpHandler to also be default-compressed).

I'm guessing there's no easy solution to my problem because it seems like a bug in IIS. IIS should not compress a response that is already compressed.

I tried adding the following to my web.config, but it had no effect:

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

(From my interpretation of the documentation, that should disable compression for dynamically generated CSS and JS.)

I also tried this, to no effect:

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

(From my interpretation of the documentation, that should disable all default compression.)

Update

In my IHttpHandler, I call context.Response.Flush at the very end. If I remove this call, the response doesn't get double-compressed. I'm fine with this as a solution. Can anyone explain why this is happening?

Update 2

My best guess is that calling Flush puts the response into such a state that IIS doesn't think the response is already compressed (and so it applies default compression). Even though in my module I can check both...

• that Response.Headers contains a Content-Encoding header and
• that Response.Filter is non-null and is one of the System.IO.Compression types.

Not sure why IIS can't determine that the response is already compressed from those facts.