“Cache-Control：max-age = 0，no-cache”但浏览器绕过服务器查询（并命中缓存）？ [英] "Cache-Control: max-age=0, no-cache" but browser bypasses server query (and hits cache)?

问题描述

Cache-Control：max-age = 0，no-缓存在所有页面上设置 - 所以我希望浏览器只使用缓存中的某些内容，如果它首先与服务器进行检查并获得 304 Not Modified $ b

然而，在按下后退按钮时，浏览器快速地在不检查服务器的情况下点击自己的缓存。

如果我打开同一页面，就像我用后退按钮打开的那样，在新选项卡中，然后它会检查服务器（并获取 303 See Other ）b / b>

请参阅下面的屏幕截图，其中显示了Chrome Developer Tools的Network选项卡中两种不同情况的输出。

我认为我可以使用 max-age = 0，no-cache 作为 no -store 其中我不希望用户通过后退按钮看到陈旧的数据（但数据为非valuab le，所以可以被缓存）。

我对 no-cache 的理解（参见

no-cache

如果no-cache指令没有指定字段名称，那么缓存不得使用该响应来满足后续请求，而不会与源服务器成功重新验证。这允许源服务器甚至通过已配置为对客户端请求返回陈旧响应的高速缓存来防止高速缓存。如果no-cache指令没有指定一个或多个字段名称，那么缓存可以使用该响应来满足后续请求，但要受制于其他缓存限制。但是，指定的字段名不得在对后续请求的响应中发送，而不会与源服务器成功重新生效。这允许源服务器防止在响应中重新使用某些头字段，同时仍允许缓存其余响应。

除名称外， no-cache 不要求响应不能存储在缓存中。它只指定缓存的响应不能被重用来为后续请求提供服务而无需重新验证，因此它是 must-revalidate，max-age = 0的简写。 code>。

由浏览器决定后续请求的资格，并根据我的理解，按钮不。这种行为在不同的浏览器引擎之间有所不同。

$ b

no-store 禁止对所有请求使用缓存响应，不仅适用于后续版本。

请注意，即使使用 no-store ，RFC实际上也允许客户端存储在历史缓冲区中使用的响应。这意味着即使已经指定了 no-store ，客户端仍然可以使用缓存响应。

后者行为涵盖了个案该页面在浏览器历史记录中以其原始页面标题进行了记录。另一个用例是各种移动浏览器的行为，在用户可能想要中止下一页完全加载之前，它们不会丢弃上一页。

有关后退按钮的行为：根据 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13

用户代理通常具有历史机制，例如返回按钮和历史列表，这些机制可用于重新显示会话中早先检索到的实体。

历史记录机制和缓存是不同的。特别是历史机制不应该试图显示资源当前状态的语义透明视图。相反，历史记录机制旨在准确显示用户在检索资源时看到的内容。

默认情况下，到期时间不适用于历史记录机制。如果实体仍处于存储状态，即使实体已过期，历史记录机制也应该显示它，除非用户特别配置代理以刷新过期的历史文档。

这意味着在使用后退按钮时不尊重任何缓存控制标题是推荐的行为。如果您的浏览器碰巧遇到了过期的过期日期，或者将 no-store 指令不仅应用于浏览器缓存，而且还应用于历史记录，实际上它已经偏离了该建议。

如何解决它：

你不能，也不应该。如果用户返回到先前访问过的页面，大多数浏览器甚至会尝试恢复视口。如果这是用户离开页面之前的原始行为，那么您可以使用像AJAX这样的延迟机制来刷新内容，否则，您甚至不应修改内容。

I'm using Chrome 40 (so something nice and modern).

Cache-Control: max-age=0, no-cache is set on all pages - so I expect the browser to only use something from its cache if it has first checked with the server and gotten a 304 Not Modified response.

However on pressing the back button the browser merrily hits its own cache without checking with the server.

If I open the same page, as I reached with the back button, in a new tab then it does check with the server (and gets a 303 See Other response as things have changed).

See the screen captures below showing the output for the two different cases from the Network tab of the Chrome Developer Tools.

I thought I could use max-age=0, no-cache as a lighter weight alternative to no-store where I don't want users seeing stale data via the back button (but where the data is non-valuable and so can be cached).

My understanding of no-cache (see here and here on SO) is that the browser must always revalidate all responses. So why doesn't Chrome do this when using the back button?

Is no-store the only option?

---

200 response (from cache) on pressing back button:

303 response on requesting the same page in a new tab:

解决方案

From http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

no-cache

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.

If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.

Other than the name implies, no-cache does not require that the response must not be stored in cache. It only specifies that the cached response must not be reused to serve a subsequent request without re-validating, so it's a shorthand for must-revalidate, max-age=0.

It is up to the browser what to qualify as a subsequent request, and to my understanding using the back-button does not. This behavior varies between different browser engines.

no-store forbids the use of the cached response for all requests, not only for subsequent ones.

Note that even with no-store, the RFC actually permits the client to store the response for use in history buffers. That means client may still use a cached response even when no-store has been specified.

Latter behavior covers cases where the page has been recorded with its original page title in the browser history. Another use case is the behavior of various mobile browsers which will not discard the previous page until the following page has fully loaded as the user might want to abort.

For clarification on the the behavior of the back button: It is not subject to any cache header, according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

That means that disrespecting any cache control headers when using the back button is the recommended behavior. If your browser happens to honor a backdated expiration date or applies the no-store directive not only to the browser cache but also to the history, it's actually already departing from that recommendation.

For how to solve it:
You can't, and you are not supposed to. If the user is returning to a previously visited page, most browsers will even try to restore the viewport. You may use deferred mechanism like AJAX to refresh content if this was the original behavior before the user left the page, but otherwise you should not even modify the content.

这篇关于“Cache-Control：max-age = 0，no-cache”但浏览器绕过服务器查询（并命中缓存）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！