Output caching still adding Cache-Control:no-cache even when it is disabled

Question

Background

A customer is running our web app. over HTTPS and are running into the (fairly well know) IE8 "file cannot be written to cache" error when they try to view a PDF/Excel/word file because the response contains the HTTP Cache-Control:no-cache directive. The thing is, it is not our app (or its config) that is adding this directive.

After a bit of investigating I discovered that the IIS7 page output caching feature can also add this header, for example

<caching enabled="false" enableKernelCache="false">
    <profiles>
        <add extension=".htm" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" />
    </profiles> 
</caching>

will have the effect of adding Cache-Control:no-cache, private to response headers.

My Question

But the surprising (IMO) thing is that even when you supposedly disable the feature (see in my config snippet above that enabled="false"), the response headers are still being sent with Cache-Control:no-cache, private.

Am I being stupid to be surprised by this (I guess I probably am)?

Answer 1

What effectively got rid of no-cache for me was adding location="Any" to the add element, which instead writes Cache-Control:public:

<caching enabled="false" enableKernelCache="false">
    <profiles>
        <add extension=".htm" ... location="Any" />
    </profiles> 
</caching>

In the absence of the location attribute, IIS defaults to Cache-Control:no-cache. Other possible values are Client, Downstream, Server, or ServerAndClient. Details here.

Answer 2

You're not alone: http://forums.iis.net/t/1152306.aspx

We also had the same problem. I haven't found any documentation about this "feature" so I'm assuming it is a bug.

We decided to just remove the caching tag and use only the clientCache tag instead.