HTTP 缓存 FAQ

什么是缓存?

Mozilla缓存机制将会保留用户通过 HTTP 下载的所有文件。 你可能觉得古怪，但是有这样的机制，我们不需要再次向服务器请求，就可以后退/前进、保存或者查看这些文件的源代码。就像离线浏览缓存的内容一样。

如果文档自带 Cache-control: no-cache 头呢?

是的，我们连 "no-cache" 的文档都会缓存的。

那么要一直保存着陈旧的内容喽?

不是的, 每份文档都会有个过期时间。当Mozilla把它们加载出来展示的时候，这个过期时间就会起作用。如果有必要，缓存文档在展示给用户之前会和服务器做下校验。

过期时间怎么计算 (有些响应是不带 Expires 头的)?

Mozilla遵循 RFC 2616 实现（第13章)。下面这个响应头会使过期时间总是在过去。 (时间是 "00:00:00 UTC, January 1, 1970"):

Cache-control: no-cache
Cache-control: no-store
Pragma: no-cache
Expires: 0

注意 "Expires: 0" 和 "Pragma: no-cache" 严格来说是无效的响应头。如果这些头字段都不存在，那么过期时间就按照 RFC 2616 第13.2章描述的算法计算。 总之我们通过可用的信息来估算响应的当前时间和生命周期时间。

当前时间通常接近0，但是会受Age头的影响，代理缓存会用这个头来表示一个文档在缓存中已经存在的时间。

The current age is usually close to zero, but is influenced by the presence of an Age header, which proxy caches may add to indicate the length of time a document has been sitting in its cache. The precise algorithm, which attempts avoid error resulting from clock skew, is described in RFC 2616 section 13.2.3.

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, then we look for an"Expires" header. 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, then we 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. This is the simplified heuristic algorithm suggested in RFC 2616 section 13.2.4.

The expiration time is computed as follows:

expirationTime = responseTime + freshnessLifetime - currentAge

where responseTime is the time at which the response was received according to the browser.

What other factors influence revalidation?

Revalidation is triggered when the user presses the reload button. It is also triggered under normal browsing if the cached response includes the "Cache-control: must-revalidate" header. Another factor is the cache validation preferences in the Advanced->Cache preferences panel. There is an option to force a validation each time a document is loaded.

How does cache validation work?

When a cached documents expiration time has been reached, it is either validated or refetched. Validation can only occur if the server provided either a strong validator or a weak validator. Cache validators are described in RFC 2616 section 13.3.2.

The "ETag" response header is an opaque-to-the-useragent value that can be used as a strong validator. If the "ETag" header is present in a response, then the client can issue an "If-None-Match" request header to validate the cached document.

The "Last-Modified" response header can be used as a weak validator. It is considered weak because it only has 1-second resolution. If the "Last-Modified" header is present in a response, then the client can issue an "If-Modified-Since" request header to validate the cached document.

When a validation request is made, the server can either ignore the validation request and response with a normal 200 OK, or it can return 304 Not Modified to instruct the browser to use its cached copy. The latter response can also include headers that update the expiration time of the cached document.

What about...?

I plan to extend this document in the future. Feel free to email me your questions or comments.