无变化搜索

key-order

布尔值。如果包含在头值中，则表示其他方面相同的 URL 之间参数顺序的差异不会导致它们被缓存为单独的条目。参数存在的差异将导致它们被单独缓存。

params

布尔值或字符串列表

• 如果作为布尔值包含在头值中，则表示其他方面相同的 URL 之间参数的差异不会导致它们被缓存为单独的条目。
• 如果作为列表包含在头值中，则表示列出的特定参数的存在不会导致其他方面相同的 URL 被缓存为单独的条目。其他参数的存在将导致它们被单独缓存。

except

字符串列表。如果包含在头值中，则表示列出的特定参数的存在将导致其他方面相同的 URL 被缓存为单独的条目。其他参数的存在不会导致它们被单独缓存。必须包含布尔值 params 指令以及 except，才能使它生效。

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

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

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

考虑用户目录登陆页面 /users 已经被缓存的情况。可以使用 id 参数来显示特定用户的信息，例如 /users?id=345。此 URL 是否应被视为缓存匹配目的下的相同，取决于应用程序的行为。

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

如果您的应用程序的行为类似于上面描述的第二个示例，您可以通过以下 No-Vary-Search 头使 /users 和 /users?id=345 都被视为缓存目的下的相同

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

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

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

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

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

No-Vary-Search: params

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

这可以通过以下方式实现

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