stale-while-revalidate 如何与 Cache-Control 标头中的 s-maxage 交互？

Question

只是想了解我为 SSR 页面指定的标题：public, s-maxage=3600, stale-while-revalidate=59。

请注意，我的stale-while-revalidate值是 59 秒，远小于s-maxage1 小时的值。我想知道当stale-while-revalidatevalue 小于 时s-maxage，到底会发生什么？标题是否被stale-while-revalidate忽略？

Answer 1

正如@DanilaVershinin 在他的回答中指出的，s-maxage和stale-while-revalidate分别应用于不同的缓存 - 共享缓存和浏览器缓存。它们彼此不重叠。

免责声明：此答案适用于max-age（而不适用s-maxage）。

将页面Cache-Control标题设置为max-age=3600, stale-while-revalidate=59意味着两件事：

1. 该页面在 3600 秒内被视为新鲜 ( max-age=3600)；
2. 此后 ( stale-while-revalidate=59) 页面将继续从过时状态继续提供服务，最多 59 秒，同时重新验证在后台完成。

stale-while-revalidate不会被忽略，它确定页面max-age通过后（即页面过时）发生重新验证时的额外时间窗口。

以下是三个时间窗口的缓存状态（基于https://web.dev/stale-while-revalidate/#live-example）：

0至3600秒	3601 至 3660	3660秒后
缓存的页面是新鲜的并且用于提供页面。没有重新验证。	缓存的页面已过时，但用于提供页面服务。重新验证在后台进行以填充缓存。	缓存的页面已过时且根本未使用。发出新请求来服务页面并填充缓存。

摘自过时内容规范的 HTTP 缓存控制扩展：

max-age一般来说，服务员会希望将和 的组合设置stale-while-revalidate为他们可以容忍的最长的总潜在保鲜期。例如，如果两者都设置为 600，服务器必须能够容忍缓存提供的响应长达 20 分钟。

由于异步验证仅在响应过时之后但在窗口结束之前发生请求时才会发生，因此 stale-while-revalidate该窗口的大小以及在此期间请求的可能性决定了所有请求在没有响应的情况下得到服务的可能性有多大。延迟。如果窗口太小，或者流量太稀疏，一些请求将落在窗口之外，并被阻塞，直到服务器可以验证缓存的响应。