当服务器提供Cache-Control: max-age=4320000
时,
新鲜度是在请求时间之后的 4320000 秒之后,还是在最后修改日期之后?
当服务器提供Cache-Control: max-age=4320000
时,
新鲜度是在请求时间之后的 4320000 秒之后,还是在最后修改日期之后?
RFC 2616第 14.9.3 节:
当缓存响应中存在 max-age cache-control 指令时,如果响应的当前年龄大于对该资源的新请求时给定的年龄值(以秒为单位),则该响应是陈旧的。响应上的 max-age 指令意味着响应是可缓存的(即“公共”),除非还存在其他一些更严格的缓存指令。
它始终基于请求的时间,而不是最后修改的日期。您可以通过在主要浏览器上进行测试来确认此行为。
tl;dr:缓存对象的年龄是它被任何缓存存储的时间,或者now() - "Date" response header
,以较大者为准。
完整回复:
接受的响应不正确。提到的 rfc 2616 在第13.2.4节中指出:
为了确定响应是新鲜的还是陈旧的,我们需要将其新鲜寿命与其年龄进行比较。年龄的计算方法见第 13.2.3 节。
在第13.2.3节中声明:
更正_received_age = max(现在 - date_value, age_value)
date_value
是响应头Date
:
HTTP/1.1 要求源服务器在可能的情况下在每个响应中发送一个 Date 标头,给出生成响应的时间 [...] 我们使用术语“date_value”来表示 Date 标头的值。
age_value
是该项目在任何缓存中存储多长时间:
本质上,Age 值是响应在来自源服务器的路径上驻留在每个缓存中的时间加上它在网络路径上传输的时间的总和。
Age
这就是为什么好的缓存提供者会在每次缓存项目时包含一个标头,以告知任何上游缓存他们缓存该项目的时间。如果上游缓存决定存储该项目,则其年龄必须以该值开始。
一个实际的例子:一个项目存储在缓存中。它是 5 天前存储的,当获取此项目时,响应标头包括:
Date: Sat, 1 Jan 2022 11:05:05 GMT
Cache-Control: max-age={30 days in seconds}
Age: {10 days in seconds}
假设now()
是 2022 年 2 月 3 日,则该项目的年龄必须按如下方式计算(为了清楚起见,四舍五入):
校正后的年龄是最大的值,即 34 天。这意味着该项目已过期且无法使用,因为 max-age 为 30 天。
RFC 提供了一个微小的附加更正,以补偿请求延迟(请参阅第 3 节,“corrected_initial_age”)。
不幸的是,并非所有缓存服务器都会包含“Age”响应标头,因此确保所有使用的响应max-age
也包含“date”标头非常重要,以便始终计算年龄。