用户代理能否在其请求中将 max-age 设置为大于零？
Can a user agent set a max-age greater than zero in its request?
我在阅读 Http 缓存 rfc 后对 max-age 行为有疑问。
场景：
用户代理
GET /foo
源服务器响应header
cache-control: max-age=120
服务器告诉用户代理请求的资源应该在 2 分钟后重新生效。
1 分几秒后，用户代理发出另一个请求，指定 max-age 1 分钟：
用户代理
cache-control: max-age=60
GET /foo
据我了解，此请求应该绕过用户代理缓存。
为什么？
尽管源服务器告诉客户端资源应该缓存 2 分钟，但用户代理需要最多 1 分钟的资源 (max-age = 60)。
从第一个 GET 开始 1 分几秒后，该资源无效（从用户代理的角度来看），请求应直接发送到源服务器（或任何其他缓存层）。
我说得对吗？
是否可以从用户代理指定大于零的 max-age？
是普通浏览器supported/honored吗？
在我工作的地方，我们有一个像这样工作的 .NET 自定义缓存机制；当客户端需要来自“最多”X 秒的缓存资源时，客户端可以指定 max-age。
来自RFC2616max-age
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 的最后几行：
If a request includes the no-cache directive, it SHOULD NOT
include min-fresh, max-stale, or max-age.
来自13.2.6 Disambiguating Multiple Responses section
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，它应该使用与 headers 中接收的日期与 [=15= 中定义的值之间的差异相匹配的存储版本].
不确定我是否正确，但正如我所理解的那样。
补充类似问题：What's the difference between Cache-Control: max-age=0 and no-cache?
无需怀疑。
RFC7234 Section 5.2.1.1 包括一个示例 max-age=5，它当然大于零。
定义也很清楚（强调我的）：
The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds.
“指定的秒数”可以是任何 non-negative 整数（在 Section 1.2.1 中定义）。
所以答案是肯定的。
另外，我上面引用的定义也解释了你场景中的缓存行为。
但在此之前，我应该更正以下内容：
Server tells user agent that the resource requested should be revalidated after 2 minutes.
不正确。
max-age=120 指令意味着服务器告诉所有缓存，而不是用户代理，响应必须在 2 分钟后被视为过时。
来自 Section 5.2.2.8（强调我的）：
The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.
如您所见，没有重新验证要求。
如果在 10 分钟后没有对同一资源的请求，则在 10 分钟后才会进行任何重新验证。
此外，来自 Section 5.2（强调我的）：
The "Cache-Control" header field is used to specify directives for caches along the request/response chain.
只是缓存，不是用户代理。
request/response 链中的每个参与者都会收到具有相同 Cache-Control header 的相同响应，但是 Cache-Control header 的预期接收者是只是缓存。
请记住，仅仅因为您收到它，并不意味着它是给您的。
对于你的场景的其余部分，你的评估是正确的。
我会在这里引用它：
After 1 minute and few seconds, User agent makes another request, specifying a max-age of 1 minute:
...
From what I understand, this request should bypass the user agent cache.
Why?
因为在请求的时候，存储响应的时间超过了 60 秒。
很明显，如果存储响应的时间是 65 秒，则不能使用它来满足带有 max-age=60 指令的请求。
因此，缓存只是服从它接收到的指令。
事实上，任何符合标准的 HTTP 缓存，无论是集成在浏览器中还是单独的，都需要遵守它接收到的指令，如 Section 5.2 中所述（大写强调来自源代码，而不是我的）：
A cache MUST obey the requirements of the Cache-Control directives defined in this section.
根据您的描述，您使用的自定义缓存机制似乎符合标准。
所以，我对开发人员的补充，特别是如果您所说的“自定义”是指“内部开发”。
我在阅读 Http 缓存 rfc 后对 max-age 行为有疑问。
场景：
用户代理
GET /foo
源服务器响应header
cache-control: max-age=120
服务器告诉用户代理请求的资源应该在 2 分钟后重新生效。
1 分几秒后，用户代理发出另一个请求，指定 max-age 1 分钟：
用户代理
cache-control: max-age=60
GET /foo
据我了解，此请求应该绕过用户代理缓存。
为什么？
尽管源服务器告诉客户端资源应该缓存 2 分钟，但用户代理需要最多 1 分钟的资源 (max-age = 60)。
从第一个 GET 开始 1 分几秒后，该资源无效（从用户代理的角度来看），请求应直接发送到源服务器（或任何其他缓存层）。
我说得对吗？
是否可以从用户代理指定大于零的 max-age？
是普通浏览器supported/honored吗？
在我工作的地方，我们有一个像这样工作的 .NET 自定义缓存机制；当客户端需要来自“最多”X 秒的缓存资源时，客户端可以指定 max-age。
来自RFC2616max-age
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 的最后几行：
If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age.
来自13.2.6 Disambiguating Multiple Responses section
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，它应该使用与 headers 中接收的日期与 [=15= 中定义的值之间的差异相匹配的存储版本].
不确定我是否正确，但正如我所理解的那样。
补充类似问题：What's the difference between Cache-Control: max-age=0 and no-cache?
无需怀疑。
RFC7234 Section 5.2.1.1 包括一个示例 max-age=5，它当然大于零。
定义也很清楚（强调我的）：
The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds.
“指定的秒数”可以是任何 non-negative 整数（在 Section 1.2.1 中定义）。 所以答案是肯定的。
另外，我上面引用的定义也解释了你场景中的缓存行为。 但在此之前，我应该更正以下内容：
Server tells user agent that the resource requested should be revalidated after 2 minutes.
不正确。
max-age=120 指令意味着服务器告诉所有缓存，而不是用户代理，响应必须在 2 分钟后被视为过时。
来自 Section 5.2.2.8（强调我的）：
The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.
如您所见，没有重新验证要求。 如果在 10 分钟后没有对同一资源的请求，则在 10 分钟后才会进行任何重新验证。
此外，来自 Section 5.2（强调我的）：
The "Cache-Control" header field is used to specify directives for caches along the request/response chain.
只是缓存，不是用户代理。
request/response 链中的每个参与者都会收到具有相同 Cache-Control header 的相同响应，但是 Cache-Control header 的预期接收者是只是缓存。 请记住，仅仅因为您收到它，并不意味着它是给您的。
对于你的场景的其余部分，你的评估是正确的。 我会在这里引用它：
After 1 minute and few seconds, User agent makes another request, specifying a
max-ageof 1 minute:...
From what I understand, this request should bypass the user agent cache. Why?
因为在请求的时候，存储响应的时间超过了 60 秒。
很明显，如果存储响应的时间是 65 秒，则不能使用它来满足带有 max-age=60 指令的请求。
因此，缓存只是服从它接收到的指令。
事实上，任何符合标准的 HTTP 缓存，无论是集成在浏览器中还是单独的，都需要遵守它接收到的指令，如 Section 5.2 中所述（大写强调来自源代码，而不是我的）：
A cache MUST obey the requirements of the Cache-Control directives defined in this section.
根据您的描述，您使用的自定义缓存机制似乎符合标准。 所以，我对开发人员的补充，特别是如果您所说的“自定义”是指“内部开发”。