4

My images are stored in azure blob storage and referenced through my web application using my azure CDN. However all images return a 304 response header. Ideally I dont want the browser to return to the CDN to check for validity at every request, instead for the browser to always use the cache. - Well for at the life of the image cache.

With my limited knowledge of Caching, I understand that the cache uses the ETag value to compare if the version of the image is the same when requested. In this case it is and the CDN returns a 304 response. But because the CacheControl header is set as public, max-age=2592000 I would hope the browser would use the cached copy of the image. I have another CDN setup that has a hosted service endpoint which returns a 200 response because I remove the ETag value.

Any help with this would be greatly appreciated.

Christo
  • 2,330
  • 3
  • 24
  • 37
  • Few questions. Did you mean 'max-age' instead of 'max-set'? Is an Expires header also in the response? What browser are we talking about here? – brettw Feb 13 '12 at 05:02
  • did mean max-age. Expires header isnt in the response and im working with firebug in firefox. – Christo Feb 13 '12 at 05:32

1 Answers1

1

When ETag "triggers" 304 response => the browser has sent If-None-Match validating request to the server. This is normally done after max-age has elapsed. You could find a good description of this here:

https://stackoverflow.com/a/500103/2550808

it is also worth mentioning, Firefox browser settings should be set to default: go to about:config page and check this settings: http://kb.mozillazine.org/Browser.cache.check_doc_frequency

Going back to your question, something might be wrong with Cache-Control header the server returns to the browser. In my modest personal experience I didn't encounter explicitly public version of the header, it would be more likely just this:

Cache-Control: max-age=3600, must-revalidate

Anyway, here is pretty good description of headers pertaining to caching:

https://www.mnot.net/cache_docs/

Alternatively, there might be other reasons for incessant re-validation to consider:

  • VARY headers in server's 200 response with the file may affect caching;
  • JavaScript calling reload on the location object, passing TRUE for bReloadSource;
Community
  • 1
  • 1
wick
  • 1,995
  • 2
  • 20
  • 31