caching - 浏览器从缓存中提供过时的授权 header

Question

我的客户端在向我的服务器发出无害请求后被注销。我控制了两端，经过大量调试，我发现发生了以下情况:

• 客户端发送带有正确授权 header 的请求。
• 服务器响应 304 Not Modified，不带任何授权 header 。
• 浏览器提供完整的响应，包括在其缓存中找到的过时的授权 header 。
• 从现在开始，客户端将使用过时的授权并被踢出。

据我所知，the browser must not cache any request containing Authorization 。尽管如此，

chrome://view-http-cache/http://localhost:10080/api/SearchHost

显示

HTTP/1.1 200 OK
Date: Thu, 23 Nov 2017 23:50:16 GMT
Vary: origin, accept-encoding, authorization, x-role
Cache-Control: must-revalidate
Server: 171123_073418-d8d7cb0 =
x-delay-seconds: 3
Authorization: Wl6pPirDLQqWqYv
Expires: Thu, 01 Jan 1970 00:00:00 GMT
ETag: "zUxy1pv3CQ3IYTFlBg3Z3vYovg3zSw2L"
Content-Encoding: gzip
Content-Type: application/json;charset=utf-8
Content-Length: 255

有趣的服务器 header 用一些内部信息替换了 Jetty 服务器 header (出于安全原因不应提供服务) - 忽略它。 curl 是这样说的:

< HTTP/1.1 304 Not Modified
< Date: Thu, 23 Nov 2017 23:58:18 GMT
< Vary: origin, accept-encoding, authorization, x-role
< Cache-Control: must-revalidate
< Server: 171123_073418-d8d7cb0 =
< ETag: "zUxy1pv3CQ3IYTFlBg3Z3vYovg3zSw2L"
< x-delay-seconds: 3
< Content-Encoding: gzip

这也发生在 Firefox 中，尽管我目前无法重现它。 The RFC继续，看起来上面链接的答案并不准确:

unless a cache directive that allows such responses to be stored is present in the response

看起来响应是可缓存的。没关系，我确实希望内容被缓存，但我不希望从缓存中提供授权 header 。这可能吗？

我的问题的解释

我的服务器过去仅在响应登录请求时才发送Authorization header 。这曾经工作得很好，新的要求带来了问题。

我们的网站允许用户任意长时间地保持登录状态(我们不做敏感业务)。我们正在更改授权 token 的格式，并且我们不想因此强制所有用户重新登录。因此，我让服务器在看到过时但有效的授权 token 时发送更新的授权 token 。因此，现在任何响应都可能包含授权 token ，但大多数响应都不包含。

浏览器缓存将仍然有效的响应与过时的授权 token 相结合。

作为解决方法，我让服务器在存在授权 token 时不发送 etag。它有效，但我更喜欢一些更干净的解决方案。

Answer 1

链接答案中的引用具有误导性，因为它省略了一个重要部分:“如果缓存是共享的”。这是正确的引用( RFC7234 Section 3 ):

A cache MUST NOT store a response to any request, unless: ... the Authorization header field (see Section 4.2 of [RFC7235]) does not appear in the request, if the cache is shared,

RFC 的这一部分基本上是一个摘要。这是完整的规则 ( RFC7234 Section 3.2 )，本质上讲的是同一件事:

A shared cache MUST NOT use a cached response to a request with an Authorization header field (Section 4.2 of [RFC7235]) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.

浏览器缓存是共享缓存吗？Introduction section of the RFC对此进行了解释。 :

A private cache, in contrast, is dedicated to a single user; often, they are deployed as a component of a user agent.

这意味着浏览器缓存是私有(private)缓存。它不是共享缓存，因此上述规则不适用，这意味着 Chrome 和 Firefox 都能正确执行其工作。

现在是解决方案。

该规范建议可以在没有授权 header 的情况下重用包含授权的缓存响应。不幸的是，它还表示该功能尚未广泛实现。

因此，我能想到的最简单也是最面向 future 的解决方案是确保不缓存任何包含授权 token 的响应。例如，每当服务器看到已过时但有效的授权 token 时，请发送一个新的有效 token 以及 Cache-Control: no-store禁止缓存。

此外，您绝不能发送带有授权 header 的 Cache-Control: Must-revalidate ，因为 must-revalidate 指令实际上允许缓存响应，包括通过共享缓存这可能会在未来造成更多问题。

... unless a cache directive that allows such responses to be stored is present in the response.

In this specification, the following Cache-Control response directives (Section 5.2.2) have such an effect: must-revalidate, public, and s-maxage.