StaticFileHandler ResponseFilter Cache-Control No-Cache returning Private on 304 NotModified


When using the StaticFileHandler.ResponseFilter to set the header “Cache-Control”: no-cache, we get a weird result as the 304 Not Modified has a “Cache-Control”: private which cause the file to not be re-validated by the browser. Note that this only seems to happen when hosting in IIS or IISExpress. Works fine when self hosting, so may be an issue with IIS.

A bit of context here, we are trying to globally have our API calls be no-store and the VirtualFileSystem be no-cache (and let the browser use If-Modified-Since to re-validate). That’s why we are using StaticFileHandler.ResponseFilter and GlobalResponseFilters instead of GlobalResponseHeaders. We tried a combinaison of both filters and GlobalResponseHeaders, but the global headers overrides the other headers set in the filters.

Tracked down in the source code to this if returning before the execution of the ResponseFilter (which is the intended behavior I suppose) and seemingly no other way than using the GlobalResponseHeaders to set the Cache-Control on the NotModified response which is not an option in our case:


The StaticFileHandler.ResponseFilter is now also being called for 304 responses from this commit. This change is available from v5.5.1+ that’s now available on MyGet.