How do I disable caching of an individual file in IIS 7 using weserver config settings

Question

Is there any way to diable the caching of a single javascript file in my ASP.NET applicaiton without disabling the caching of any other files in the application?

It is running on IIS 7 in Azure, so to me it seems that my only options of controlling this are within the webserver tags.

I currently use the folowwing config, but this is disabling cache on all files.

     <modules runAllManagedModulesForAllRequests="true"/>

    <staticContent>
      <clientCache cacheControlMode="DisableCache"/>
    </staticContent>

  </system.webServer>

I just want to disable cache of a single javascript file that changes quite often.

Is it possible?

Answer 1

You're going to want to look at the System.WebServer/Caching class, where you can apply a caching profile to particular extensions. This will at least enable you to control it for all Javascript files ending with the .js.

<system.webServer>
...

   <caching>
      <add extension=".js" policy="DontCache" kernelCachePolicy="DontCache" />
   </caching>

</system.webServer>

That should disable .js caching on both process and kernel caching from the cloud.

I think you can create this web.config in a folder that contains just your file and it will disable caching for .js only at that folder level. I honestly have not tried that myself, so just a suggestion you could test.

---

Beyond that, take a look at the documentation for IIS related to caching config:

/Caching: http://www.iis.net/ConfigReference/system.webServer/caching

/Caching/Profiles: http://www.iis.net/ConfigReference/system.webServer/caching/profiles

/Caching/Profiles/Add: http://www.iis.net/ConfigReference/system.webServer/caching/profiles/add

Hopefully that, plus some research on those config tags will help.

If not, I'd recommend looking into implementing a custom HTTP Module that you can insert into the IIS request pipe, which can filter your caching control down to that particular file

** for what its worth this is just IIS behavior and won't be different in or out of Azure, so you could easily test this local without bothering with the Dev fabric or Azure testing.