Is it possible to control Cache-Control headers in IIS for different static file types?

Question

In IIS, can I configure it to return different cache-control headers for different static file types in the same folder?

I'm aware that I can use the HTTP Headers feature to set Expires Immediately, but that seems to affect all content. Is there a way to do it for specific file extensions for static content?

Answer 1

While not an ideal answer, I did find a work-around. In my application, I have control over where my JS, CSS, and other similar files live in the directory structure. What I did was put a web.config in the IIS root directory with these lines (among others, unrelated):

<configuration>
  <system.webServer>
     <staticContent>
       <clientCache cacheControlMode="DisableCache" setEtag="true" />
     </staticContent>
  </system.webServer>
</configuration>

This sets the default in IIS that nothing should be cached. This is where the HTML page (index.html) for my single-page-application (SPA) lives, so that's what I want.

Then, in immediate subdirectories for images, JS, CSS, etc, I have web.config files with the following:

<configuration>
  <system.webServer>
     <staticContent>
       <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="14.00:00:00" setEtag="true" />
     </staticContent>
  </system.webServer>
</configuration>

You can of course set the age to whatever you want. I am starting with 14 days for now until I'm sure I everything right, then I will probably bump that to several months.

This way, the HTML of my SPA will never get cached, but all the JS/CSS/images will live as long as I want. When I rebuild the project for next deployment, web-pack will generate new file names for the packed JS and CSS, so no cache problem there. The HTML file will be the same name of course, but the included JS file names will be different. So it's key that the HTML file not ever be cached, which this setup accomplishes.

IIS should really make this simpler. A cache-by-file-type config would work perfectly and not require strict directory structure management, which not all projects have the flexibility to follow.