87

My problem is: sometimes browser over-cached some resources even if i've already modified them. But After F5, everything is fine.

I studied this case whole afternoon. Now i completely understood the point of "Last-Modified" or "Cache-Control". And i know how to solve my issue (just .js?version or explicit max-age=xxxx). But the problem is still unsolved: how does browser handle the response header without "Cache-Control" like this:

Content-Length: 49675
Content-Type: text/html
Last-Modified: Thu, 27 Dec 2012 03:03:50 GMT
Accept-Ranges: bytes
Etag: "0af7fcbdee3cd1:972"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 24 Jan 2013 07:46:16 GMT

They clearly cache them when "Enter in the bar"

enter image description here

rhapsodyn
  • 3,272
  • 5
  • 29
  • 36
  • 1
    There is no default. That response header provides no **Expires:** `[a date]` or **Cache-Control:** `max-age=[seconds]`. Because it provides no hints, the client will use whatever heuristics it likes (e.g. cache for 5 minutes). It is entirely at the discretion of the client, including looking at that `Last-Modified` date, making a *guess* how long the content might be valid for. If you don't specify anything: you have no promises of anything. (https://stackoverflow.com/a/49637255/12597) – Ian Boyd Jan 20 '22 at 05:28
  • see https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#heuristic_caching – mb21 Aug 02 '22 at 09:21

6 Answers6

24

RFC 7234 details what browsers and proxies should do by default:

Although caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
22

The freshness lifetime is calculated based on several headers. If a "Cache-control: max-age=N" header is specified, then the freshness lifetime is equal to N. If this header is not present, which is very often the case, it is checked if an Expires header is present. If an Expires header exists, then its value minus the value of the Date header determines the freshness lifetime. Finally, if neither header is present, look for a Last-Modified header. If this header is present, then the cache's freshness lifetime is equal to the value of the Date header minus the value of the Last-modified header divided by 10.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#Freshness

rohithpr
  • 6,050
  • 8
  • 36
  • 60
kouut
  • 221
  • 2
  • 2
  • Freshness is only one element of caching. There is no guarantee that this is the factor causing the cache to be used. As a side note, this link can be used without internationalization for the english version. – Luke Exton Jan 18 '17 at 09:09
  • There is no rules say that the file will be cached only when set cache-control or expires. A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching. – kouut Jan 18 '17 at 10:58
  • Link to caching faq does seem to exist anymore. Please reference english pages next time. – robsch Oct 01 '18 at 07:35
  • So basically the longer it's been since last modified, the less frequently the browser will refetch the resource? – Drazen Bjelovuk Sep 01 '22 at 16:57
21

Caching is usually enabled by default in browers, so cache-control can be used to either customise this behaviour or disable it.

Although caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses. [https://www.rfc-editor.org/rfc/rfc7234#section-2]

The time the browser considers a cached response fresh is usually relative to when it was last modified:

Since origin servers do not always provide explicit expiration times, a cache MAY assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field values (such as the Last-Modified time)... If the response has a Last-Modified header field (Section 2.2 of [RFC7232]), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. [https://www.rfc-editor.org/rfc/rfc7234#section-4.2.2]

This post has details of how the different browsers calculate that value.

Community
  • 1
  • 1
Jon
  • 1,084
  • 11
  • 23
12

The default cache-control header is : Private

A cache mechanism may cache this page in a private cache and resend it only to a single client. This is the default value. Most proxy servers will not cache pages with this setting.

Please see http://msdn.microsoft.com/en-us/library/ms524721%28v=vs.90%29.aspx

theDmi
  • 17,546
  • 6
  • 71
  • 138
SWD
  • 457
  • 1
  • 3
  • 9
0

Without the cache control header the browser requests the resource every time it loads a new(?) page. Hitting F5 you invalidate (or even logically remove) any cached item within that page forcing the complete reload by acting as no local version is available - I am unsure if the browser removes those resources from cache before requesting them again.

The funny part is that there are some 'additional' settings within some browsers that cause some optimizations like requesting a resource only once per page loading. If you have an image that changes for every request like a counter you will see only one version of this image even if you use it multiple times.

The next one is that the browser reuses images that are not explicitly set as nocache by applying some sort of local 'prefered' caching. If you want to have a request every time you need to set it to revalidate and set expired to -1 or something like that.

So depending on the resource specifying nothing often trigger some defaults that are not the same you would expect from reading the specs.

There might be also different behaviour regarding whether the source appears to be local, a drive or a real distant internet server. Saidly not all browsers are acting differently and I am quite limited.

What helps is to check out www.google.com and look for the tracking pixel their page requests (two 1x1 pixel requested from metrics.gstats.com with random part on the subdomain).

If you use firebug to check out the header you see that they specify the nocache directives in any fashion possible. The header reads like this:

Alternate-Protocol  443:quic
Cache-Control   no-cache, must-revalidate
Content-Length  35
Content-Type    image/gif
Date    Mon, 25 Nov 2013 14:33:30 GMT
Expires Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified   Tue, 14 Aug 2012 10:47:46 GMT
Pragma  no-cache
Server  sffe
X-Content-Type-Options  nosniff
X-Firefox-Spdy  3
X-XSS-Protection    1; mode=block

Try this as a setting and check if this solves the issue that the browser did not pick up your changed resources. The must-revalidate directive will cause even proxy caches to request a resource every time and check for 304 Not Modified replies.

I currently experience something similar. I have a localhost connection setting the etag and all that happends is that the cache never ask. I did not set caching information or alike. Alone specifying an etag seams to cause FireFox to not request the resource again. So I experience something similar to your problem.

Martin Kersten
  • 5,127
  • 8
  • 46
  • 77
  • no-cache already implies that it must revalidate every time. Therefore, in this case it is sufficient just no-cache – Klimashkin Feb 26 '14 at 19:24
  • Regarding "Without the cache control header the browser requests the resource every time it loads a new(?) page", that doesn't seem to be the case with Google Chrome. It seems to cache those items indefinitely. (I'm not sure about the other browsers.) – Sam May 18 '15 at 05:05
  • `Hitting F5 you invalidate (or even logically remove) any cached item within that page forcing the complete reload` That's not right. This would only cause the browser to check for updated resources, it doesn't invalidate the current cache. Some browsers can do this however when ctrl f5 combination is pressed. – SilverlightFox Oct 28 '16 at 05:19
0

In your case, you have Etag: "0af7fcbdee3cd1:972" in response header, so its also cached.

DappWind
  • 666
  • 6
  • 6
  • Only if If-None-Match with matching ETag is sent, and even then it would return 304 Not Modified if it matches. – tjmoore Oct 24 '19 at 08:58