
Here’s something that confused me recently. I was debugging some caching issue, and it looked like the ASP.NET (framework) site wasn’t actually using the output cache settings.
The problem was that I was looking at the response headers, and it kept showing the Cache-Control no-cache
header value. When I debugged the controller however, I noticed that it didn’t always hit the breakpoint, so cache was working.
Turns out the location of the cache profile was set to server
.
<add name="somepage" duration="60" location="Server" />
Setting the location attribute to server
makes ASP.NET cache the output in memory of your server, and it sets the response header to no-cache
. That way, proxies like Cloudflare won’t cache the response, and you can do fancy stuff in your ASP.NET app using internal data to vary your cached responses (see VaryByCustom
), and have them cached in memory on your server.
The upside is you can vary your output cache using information Cloudflare or Varnish don’t know. The downside is that this means your servers will get more hits and the more servers you are using in a load balancer setup, the less effective your cache will be.
If you drop the location attribute, the Cache-Control
header will be set to whatever time you have set in your cache profile, and proxies can start caching the results.