http - 对于可以更改的内容，哪些是与缓存相关的最佳 HTTP header ？

Question

我们有几个文件是通过 HTTP 提供的，并且会不时更改。

我们应该在 HTTP 响应中返回哪些与缓存相关的 HTTP header ，以优化浏览器加载速度，同时强制浏览器验证它是否具有文件的最新版本？

我们已经设置了一个带有过去日期的“过期” header (目前似乎已达成共识)。

但是有些人建议设置这个标题:

Cache-Control: no-cache, no-store, must-revalidate

但此 header 的问题在于它阻止浏览器保留文件的本地副本，因此每次都会下载文件，即使它没有更改，也会返回 200 响应代码。

如果我只是使用:

Cache-Control: no-cache

然后浏览器(至少 Firefox 14 和 Chrome 20)保留一个本地副本，发送 If-Modified-Since 和 If-None-Match header ，以及服务器返回 304 代码，文件内容未下载。 对于这些随时可能更改的文件，这是最佳行为。

问题是我不知道仅仅设置“no-cache”是否足以强制所有浏览器(包括旧的但仍在使用的版本)和代理服务器使用服务器重新验证其本地缓存的副本。

最后，Pragma: no-cache header 怎么样？它也应该包含在 HTTP 响应中吗？

Answer 1

Google 开发者文档有一个 nice documentation on caching并提供了一些不错的模式供使用。

例如，它有一个定义最佳缓存控制策略的流程图。

此外，它定义了一个很好的模式来为文件添加指纹并设置更长的过期时间，例如一年。

• Locally cached responses are used until the resource 'expires'
• Embedding a file content fingerprint in the URL enables us to force the client to update to a new version of the response
• Each application needs to define its own cache hierarchy for optimal performance

The ability to define per-resource caching policies allows us to define “cache hierarchies” that allow us to control not only how long each is cached for, but also how quickly new versions are seen by visitor. For example, let’s analyze the above example:

• The HTML is marked with “no-cache”, which means that the browser will always revalidate the document on each request and fetch the latest version if the contents change. Also, within the HTML markup we embed fingerprints in the URLs for CSS and JavaScript assets: if the contents of those files change, than the HTML of the page will change as well and new copy of the HTML response will be downloaded.
• The CSS is allowed to be cached by browsers and intermediate caches (e.g. a CDN), and is set to expire in 1 year. Note that we can use
  the “far future expires” of 1 year safely because we embed the file
  fingerprint its filename: if the CSS is updated, the URL will change
  as well.
• The JavaScript is also set to expire in 1 year, but is marked as private, perhaps because it contains some private user data that the
  CDN shouldn’t cache.
• The image is cached without a version or unique fingerprint and is set to expire in 1 day.

The combination of ETag, Cache-Control, and unique URLs allows us to deliver the best of all worlds: long-lived expiry times, control over where the response can be cached, and on-demand updates