We have been having a problem with Chrome caching a resource on our Glassfish server. The expires and no-cache headers are not being sent and the resource (an approximately 4 MB SWF file) is being cached by Chrome — despite the presence of the Last-Modified header.
Sometimes Chrome will get a 304 code, and other times it simply does a 200 (from cache). I understand the 304 — Chrome is likely checking the most recent Last-Modified date with the cached version to decide. But other times it does the 200 (from cache), which does not return any header information and appears that Chrome is simply assuming the file hasn't been modified instead of checking.
Google's own site states the following:
HTTP/S supports local caching of static resources by the browser. Some
of the newest browsers (e.g. IE 7, Chrome) use a heuristic to decide
how long to cache all resources that don't have explicit caching
headers.
But this does not provide a definitive answer. Is this heuristic published anywhere? I realize there may not be a fixed answer (like 30 days), but some general guidelines would be useful. Furthermore, if Last-Modified is being set, I don't understand why Chrome isn't bothering to check that first.
Best Answer
The time the browser considers a cached response fresh is usually relative to when it was last modified:
The details of how Chrome (and other browsers) calculate that value, can be found in the source code (An example from Chrome v49). It would appear that Chrome also calculates the value relative to the Last-Modified header.
(Credit to this post)