我在阅读 Http Cache rfc 后对max-age行为有疑问。
场景：
用户代理
GET /foo
源站响应标头
cache-control: max-age=120
服务器告诉用户代理，请求的资源应在 2 分钟后重新验证。
1分零几秒钟后，用户代理发出另一个请求，指定 1 分钟的max-age：
用户代理
cache-control: max-age=60
GET /foo
据我了解，此请求应绕过用户代理缓存.
为什么？
尽管源服务器告诉客户端资源应缓存 2 分钟，但用户代理需要最多 1 分钟前的资源 (max-age = 60).
从第一个GET开始 1 分零几秒钟后， 该资源无效(从用户代理的角度来看)，请求应直接发送到源服务器(或任何其他缓存层)。
我说的对吗？ 是否可以从用户代理中指定大于零的max-age？ 它是否受到常见浏览器的支持/支持？
在我工作的地方，我们有一个 .NET 自定义缓存机制，其工作原理如下;当客户端需要缓存中的资源"最多"X 秒时，可以指定一个max-age。
没有必要怀疑。 RFC7234 第 5.2.1.1 节包括一个示例max-age=5当然大于零。 定义也很明确(强调我的)：
"max-age"请求指令指示客户端不愿意接受年龄大于指定秒数的响应。
"指定的秒数"可以是任何非负整数(在第 1.2.1 节中定义)。 所以答案是肯定的。
此外，我上面引用的定义还解释了方案中的缓存行为。 但在我开始之前，我应该纠正以下几点：
服务器告诉用户代理，请求的资源应在 2 分钟后重新验证。
不對。
max-age=120指令意味着服务器告诉所有缓存(而不是用户代理)响应必须在 2 分钟后被视为过时。 来自第 5.2.2.8 节(强调我的)：
"max-age"响应指令指示响应在其年龄大于指定的秒数后将被视为过时。
如您所见，没有重新验证要求。 如果直到 10 分钟后才对同一资源发出请求，则在 10 分钟后才会有任何重新验证。
另外，从第 5.2 节(强调我的)：
"缓存控制"标头字段用于指定请求/响应链中缓存的指令。
只是缓存，而不是用户代理。
请求/响应链中的每个参与者都会收到具有相同 Cache-Control 标头的相同响应，但 Cache-Control 标头的预期接收者只是缓存。 请记住，仅仅因为你收到了它，并不意味着它适合你。
对于方案的其余部分，评估是正确的。 我在这里引用它：
1分零几秒钟后，用户代理发出另一个请求，指定 1 分钟的
max-age：。
据我了解，此请求应绕过用户代理缓存。 为什么？
因为在请求时，存储响应的期限超过 60 秒。 很明显，如果存储响应的年龄是 65 秒，则它不能用于满足具有max-age=60指令的请求。 因此，缓存只是服从它收到的指令。
事实上，任何符合标准的HTTP缓存，无论是集成在浏览器中还是单独的，都需要遵守它收到的指令，如第5.2节所述(大写强调来自源代码，而不是我的)：
缓存必须遵守本节中定义的缓存控制指令的要求。
根据您所描述的内容，您工作的自定义缓存机制似乎符合标准。 因此，我对开发人员的补充，特别是如果"自定义"是指"内部开发"。
从RFC2616最大年龄
When an intermediate cache is forced, by means of a max-age=0
directive, to revalidate its own cache entry, and the client has
supplied its own validator in the request, the supplied validator
might differ from the validator currently stored with the cache
entry. In this case, the cache MAY use either validator in making
its own request without affecting semantic transparency.
However, the choice of validator might affect performance. The
best approach is for the intermediate cache to use its own
validator when making its request. If the server replies with 304
(Not Modified), then the cache can return its now validated copy
to the client with a 200 (OK) response. If the server replies with
a new entity and cache validator, however, the intermediate cache
can compare the returned validator with the one provided in the
client's request, using the strong comparison function. If the
client's validator is equal to the origin server's, then the
intermediate cache simply returns 304 (Not Modified). Otherwise,
it returns the new entity with a 200 (OK) response.
If a request includes the no-cache directive, it SHOULD NOT
include min-fresh, max-stale, or max-age.
从 RFC 的最后一行：
如果请求包含无缓存指令，则不应 包括最小新鲜、最大陈旧或最大老化。
从 13.2.6 消除多个响应的歧义部分
When a client tries to revalidate a cache entry,
and the response it receives contains a Date header that
appears to be older than the one for the existing entry,
then the client SHOULD repeat the request
unconditionally, and include
Cache-Control: max-age=0
to force any intermediate caches to validate their copies directly with the origin server, or
Cache-Control: no-cache
to force any intermediate caches to obtain a new copy from the origin server.
If the Date values are equal, then the client MAY use either response
(or MAY, if it is being extremely prudent, request a new response).
Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same
second, if their expiration times overlap.
我的理解是，从客户端(用户代理)max-age=0可以用作使用最新存储版本的机制，与no-cache相反，它将重新获取资源。
curl -I -H 'Cache-Control: no-cache' http://example.com
因此，如果使用值大于零的max-age，则应使用与标头中接收的日期与max-age中定义的值之间的差异相匹配的存储版本。
不知道我是否严谨，但就像我一样不可靠。
补充类似的问题：缓存控制：max-age=0 和无缓存有什么区别？