在阅读Http Cache rfc后,我对max-age
行为表示怀疑。
情景:
用户代理
GET /foo
源服务器响应标头
cache-control: max-age=120
服务器告诉用户代理在2分钟后应该重新验证所请求的资源。
1分钟后,用户代理发出另一个请求,指定{1}分钟为1分钟:
用户代理
max-age
根据我的理解,此请求应绕过用户代理缓存
为什么呢?
虽然Origin Server告诉客户端资源应该缓存2分钟,但用户代理需要一个最多1分钟的资源(cache-control: max-age=60
GET /foo
)。
从第一个max-age = 60
开始1分钟和几秒后,该资源无效(从用户代理的角度来看),请求应直接进入原始服务器(或任何其他缓存层)。
我是对的吗?
是否可以从用户代理指定大于零的GET
?
它是否受到常见浏览器的支持/尊重?
在我工作的地方,我们有一个.NET自定义缓存机制,就像这样工作;客户端可以在需要来自缓存的资源时指定max-age
,该资源是“AT MOST”X秒。
答案 0 :(得分:5)
没有必要怀疑。
RFC7234 Section 5.2.1.1包含一个示例max-age=5
,当然大于零。
定义也很明确(强调我的):
" max-age" request directive指示客户不愿意接受年龄大于指定秒数的响应。
"指定的秒数"可以是任何非负整数(在Section 1.2.1中定义)。 所以答案肯定是肯定的。
此外,我上面引用的定义也解释了场景中的缓存行为。 但在我谈到之前,我应该纠正以下问题:
服务器告诉用户代理在2分钟后应该重新验证所请求的资源。
不正确的。
max-age=120
指令意味着服务器告诉所有缓存,而不是用户代理,必须在2分钟后将响应视为过时。
来自Section 5.2.2.8(强调我的):
" max-age"响应指令表示在其年龄大于指定的秒数后,响应被视为陈旧。
如您所见,没有重新验证要求。 如果在10分钟之后没有对同一资源的请求,那么在10分钟之后将无法进行任何重新验证。
此外,来自Section 5.2(强调我的):
" Cache-Control" header字段用于在请求/响应链中指定 for caches 。
只是缓存,而不是用户代理。
请求/响应链中的每个参与者都使用相同的Cache-Control标头接收相同的响应,但Cache-Control标头的预期接收者只是缓存。 请记住,仅仅因为你收到它,并不意味着它适合你。
对于您的其他方案,您的评估是正确的。 我在这里引用它:
1分钟后,用户代理发出另一个请求,指定{1}分钟为1分钟:
...
据我所知,此请求应绕过用户代理缓存。 为什么呢?
因为在请求时,存储的响应的年龄超过60秒。
显而易见的是,如果存储的响应的年龄是例如65秒,则它不能用于满足具有max-age
指令的请求。
因此,缓存只是服从它收到的指令。
事实上,任何符合标准的HTTP缓存无论是集成在浏览器中还是单独的都需要遵守它收到的指令,如Section 5.2中所述(来自源代码的大写重点,而不是我的):
缓存必须遵守本节中定义的Cache-Control指令的要求。
根据您的描述,您在工作中使用的自定义缓存机制似乎符合标准。 所以,我对开发人员的补充,特别是通过" custom"你的意思是"在家里开发"。
答案 1 :(得分:1)
来自RFC2616 max-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的最后几行:
如果请求包含no-cache指令,则不应该 包括min-fresh,max-stale或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
,则应使用与标题中收到的日期之间的差异匹配的存储版本和max-age
中定义的值。
不确定如果我是正确的但是我不合时宜。
补充类似问题:What's the difference between Cache-Control: max-age=0 and no-cache?