No-Vary-Search header

实验性: 这是一项实验性技术
在生产中使用此技术之前,请仔细检查浏览器兼容性表格

HTTP No-Vary-Search 响应头指定了一组规则,用于定义 URL 的查询参数如何影响缓存匹配。这些规则决定了具有不同 URL 参数的相同 URL 是否应作为单独的浏览器缓存条目保存。

这允许浏览器在 URL 参数不匹配但返回相同内容时,重用现有资源,以避免再次获取资源的开销。

头类型 响应头
禁止请求头

语法

http
No-Vary-Search: key-order
No-Vary-Search: params
No-Vary-Search: params=("param1" "param2")
No-Vary-Search: params, except=("param1" "param2")
No-Vary-Search: key-order, params, except=("param1")

指令

key-order 可选

表示如果 URL 中参数的顺序是唯一的区别,则 URL 不会作为单独的条目进行缓存。其他参数的出现导致 URL 单独缓存。

params 可选

布尔值或字符串列表

  • 作为布尔值 (params),它表示仅参数不同的 URL 不会作为单独的条目进行缓存。
  • 一个空格分隔的字符串内部列表 (params=("param1" "param2"))。表示仅通过列出的参数不同的 URL 不会作为单独的条目进行缓存。其他参数的出现导致它们单独缓存。
except 可选

一个空格分隔的字符串内部列表 (except=("param1" "param2"))。表示仅通过列出的参数不同的 URL 作为单独的条目进行缓存。必须包含布尔值 params 指令才能使其生效 (params, except=("param1" "param2"))。不在 except= 列表中的其他参数的出现不会导致 URL 作为单独的条目进行缓存。

描述

与 Speculation Rules API 的关系

Speculation Rules API 支持使用 No-Vary-Search 头部来重用具有不同 URL 参数(如果它们包含在 No-Vary-Search 头部中)的现有预取或预渲染页面。

警告:将预渲染与 No-Vary-Search 一起使用时必须格外小心,因为页面可能最初是使用不同的 URL 参数预渲染的。No-Vary-Search 用于从服务器提供相同资源,但客户端出于各种原因(客户端渲染、用于分析测量的 UTM 参数等)使用的 URL 参数。由于初始预渲染可能用于不同的 URL 参数,因此任何依赖它们的代码都应仅在预渲染激活后运行。

Speculation Rules API 还可以包含一个 expects_no_vary_search 字段,它指示浏览器通过猜测规则接收预取/预渲染请求的文档的预期 No-Vary-Search 值(如果有)。浏览器可以使用此信息提前确定是等待现有预取/预渲染完成,还是在猜测规则匹配时启动新的获取请求更有效。请参阅“expects_no_vary_search”示例,了解如何使用此功能。

示例

允许来自参数顺序不同的 URL 的响应匹配相同的缓存条目

例如,如果你有一个搜索页面,它将其搜索条件存储在 URL 参数中,并且你无法保证每次都会以相同的顺序将参数添加到 URL,那么你可以使用 key-order 允许来自除了参数顺序不同之外其他都相同的 URL 的响应匹配相同的缓存条目。

http
No-Vary-Search: key-order

当此头部添加到关联的响应时,以下 URL 在搜索缓存时将被视为等效

https://search.example.com?a=1&b=2&c=3
https://search.example.com?b=2&a=1&c=3

然而,不同 URL 参数的存在将导致这些 URL 单独缓存。例如

https://search.example.com?a=1&b=2&c=3
https://search.example.com?b=2&a=1&c=3&d=4

以下示例说明了如何在缓存匹配的上下文中控制哪些参数被忽略。

允许来自具有不同参数的 URL 的响应匹配相同的缓存条目

考虑一种情况,用户目录着陆页 /users 已被缓存。id 参数可能用于显示特定用户的信息,例如 /users?id=345。此 URL 是否应被视为缓存匹配的同一 URL 取决于应用程序的行为

  • 如果此参数的作用是加载一个包含指定用户信息的新页面,则来自此 URL 的响应应单独缓存。
  • 如果此参数的作用是在同一页面上突出显示指定用户,并可能显示一个弹出面板显示其数据,那么浏览器最好使用 /users 的缓存响应。这可以改善用户页面的加载性能。

如果你的应用程序行为与上面描述的第二个示例类似,你可以通过如下所示的 No-Vary-Search 头部,使 /users/users?id=345 在缓存目的上被视为相同:

http
No-Vary-Search: params=("id")

注意:如果使用 params 将参数从缓存键中排除,则无论它出现在参数列表中的哪个位置,如果它包含在 URL 中,它都将在缓存匹配中被忽略。

允许来自具有多个不同参数的 URL 的响应匹配相同的缓存条目

假设你还有 URL 参数,用于按升序或降序字母顺序对页面上的用户列表进行排序,并指定显示 UI 字符串的语言,例如 /users?id=345&order=asc&lang=fr

你可以让浏览器在考虑缓存匹配时忽略所有这些参数,如下所示:

http
No-Vary-Search: params=("id" "order" "lang")

注意:作为结构化字段,参数应该是空格分隔的带引号字符串,如上所示,而不是逗号分隔的(开发人员可能更习惯)。

如果你希望浏览器在缓存匹配时忽略所有这些参数以及可能存在的任何其他参数,你可以使用布尔形式的 params

http
No-Vary-Search: params

指定导致缓存匹配失败的参数

假设应用程序行为不同,/users 指向主用户目录着陆页,而 /users?id=345 指向特定用户的完全独立的详细信息页。在这种情况下,你希望浏览器在缓存匹配时忽略上面提到的所有参数,除了 id,它的存在会导致浏览器不匹配 /users 缓存条目并从服务器请求 /users?id=345

这可以通过以下方式实现

http
No-Vary-Search: params, except=("id")

规范

规范
No-Vary-Search HTTP 响应头字段
# 第 2 节

浏览器兼容性

另见