caching - 无法缓存 main_frame 请求

Question

我正在开发一个 chrome 扩展，它可以修改 http 响应 header 。 https://chrome.google.com/webstore/detail/super-cache/fglobbnbihckpkodmeefhagijjcjnbeh/details

我无法缓存 main_frame 请求。不过，我可以控制静态请求的缓存。

例如，如果我点击 http://apple.com我收到以下 main_frame header 。

Accept-Ranges:bytes
Cache-Control:max-age=276
Connection:keep-alive
Content-Encoding:gzip
Content-Length:3310
Content-Type:text/html; charset=UTF-8
Date:Tue, 12 Mar 2013 09:24:12 GMT
Expires:Tue, 12 Mar 2013 09:28:48 GMT
Server:Apache
Vary:Accept-Encoding

但是每次我点击该 url 时，浏览器都会尝试访问服务器并最终收到 200 响应。我已经尝试了所有可能的组合，可以将 header 设置为在 main_frame 上启用缓存。

我希望当用户从 chrome 导航栏中点击 url 并且不发出任何请求时。

Answer 1

您的响应 header 中缺少某种缓存验证。 ETag header 可用于控制这一点，方法是向其中添加可标识唯一响应的值。您可以在Apache ETag documentation中阅读一些相关内容。 ，但我只需在示例的响应 header 中包含 ETag: [filename] 即可:

Accept-Ranges:bytes
Cache-Control:max-age=276
Connection:keep-alive
Content-Encoding:gzip
Content-Length:3310
Content-Type:text/html; charset=UTF-8
Date:Tue, 12 Mar 2013 09:24:12 GMT
Expires:Tue, 12 Mar 2013 09:28:48 GMT
Server:Apache
ETag: File:"somefile.html"
Vary:Accept-Encoding

这些 ETag 值可以包含几乎任何内容，例如文件名、文件大小、自定义值......可以用分号 ; 分隔。如果值包含空格，则将它们括在双引号 " 中。例如:

ETag: File:"YouTube_cd_Fdly3rX8.jpg"; Size:12169

与Cache-Control、Expires和其他一些可能会改变的 header 值(当包含在内并且浏览器知道如何解释它们时)一起，将构成浏览器的基础缓存验证器。

查看示例响应 header ，您可能希望将 Cache-Control 中的 max-age 值增加到更高的值，正如您的示例所示客户端应仅缓存 276 秒。 Expires header 值似乎也有点短。

有关如何设置这些值以及浏览器如何验证缓存控制 header 的更多信息，请参阅 RFC2616, Section 14.9 。

编辑:经过进一步调试、检查并重新检查 Chrome 缓存验证的行为，事实证明它确实不尊重正确设置的 Cache-Control 响应 header 。应 OP 的要求，我已向 Chrome 支持报告此问题:

Chrome, Version 25.0.1364.172 m

Disrespecting Cache-Control on main document requests when serving static files from a web server, while respecting same header response on linked contents.

Test setup:

Requesting a static HTML document from a web server (MIME text/html), that contains another static HTML document withing an IFRAME (also MIME text/html). The IFRAME served document has same response headers attached to it by a web server response as the main document:

Date: Thu, 21 Mar 2013 16:29:28 GMT
Expires: Thu, 21 Mar 2013 16:33:59 GMT
Cache-Control: max-age=301, max-stale=299, only-if-cached

Expected behavior:

Main document and the document served within an IFRAME will be cached locally with initial request for the duration of at least 301 (max-age) seconds, and additional 299 (max-stale) seconds for normal (non-forced) load requests. Any subsequent requests within this time-frame of 301 seconds that aren't expected to invalidate local cache (such as forced-refresh with CTRL+F5 or Reload context menu command) and are initiated by a normal page load request (e.g. re-entering relevant URL in the address bar) will be loaded from the local cache with a status message 200 OK (from cache), if none of the local cache controlling information indicates it otherwise (same URL, requested within valid cache time-frame, document was tagged to be cached in its response headers correctly).

Problem:

The main document is not loaded via its cached copy and an additional request is made to the web server, resulting in a status code 304 Not Modified. The document within an IFRAME however is loaded from the local cache correctly and results in a status message 200 OK (from cache).

Notes:

None of the cache-control tags or any combination of their values seem to have any positive effect on the behavior of local cache for the main document. Including a non-unique ETag value does not resolve the problem of caching main document either. Other major vendor browsers (tested in IE, Firefox, Opera) respect Cache-Control headers on main document.