WebDrawer and Cache-Control
Background
I occasionally get asked about setting the Cache-Control headers on WebDrawer responses. By default WebDrawer sets the Cache-Control header to 'private', which means that the only place the content should be cached is in the end user's browser, not on any intermediate servers.
No-Cache
It seems that there are various certification tools that require cache-control headers other than 'private' be sent, for example No-Cache or No-Store. While it is not possible to stop WebDrawer from sending private we can send these other directives in addition.
How To
Adding the customHeaders element within system.WebServer/httpProtocol (in web.config) will allow you to add options to cache-control. The example below will result in the Cache-Control response header being set to 'private,No-Cache'. Given that 'No-Cache' is more restrictive than 'private' this is equivalent to setting the Cache-Control header to 'No-Cache'.
<system.webServer> <httpProtocol> <customHeaders> <clear /> <add name="Cache-Control" value="No-Cache"/> </customHeaders> </httpProtocol> ... </system.webServer>
What about things I do want to cache?
The setting above will set the Cache-Control header on all responses, including CSS, JavaScript and images, you may not want to do this. We can switch these off by adding something similar to the above in the location element for the paths in which these static files are found. Each of the paths 'scripts', 'css' and 'images' already has a location element in the WebDrawer web.config, we can modify each of these to look like the 'scripts' one below, this will remove any cache-control header set above.
<location path="scripts" inheritInChildApplications="false"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web> <system.webServer> <httpProtocol> <customHeaders> <clear /> <remove name="Cache-Control" /> </customHeaders> </httpProtocol> </system.webServer> </location>
Does this matter?
The fact that non-static WebDrawer pages (e.g. any search, record details etc) do not contain cache validation headers (such as Last-Modified or ETag) means that it is very unlikely that they will be cached on intermediate servers (as discussed here), however you may still wish to explicitly forbid this. In addition, even though a browser is most likely to reload a dynamic page it is still likely to cache it on the user's local machine (in Google Chrome use chrome://cache to view cached pages). Security concerns may mean you wish to prevent pages being cached locally, in which case you would set the header 'No-Store'.
More Information
Here are some posts I have found useful in discussing Cache-Control:
- A beginners Guide
- Http Caching (at Google Developers)
- Caching when you least expect it