What's default value of cache-control?

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"

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.

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.

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

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

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.

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