HTTP-заголовок No-Vary-Search ответа задаёт набор правил, определяющих, как параметры запроса URL влияют на сопоставление с кэшем. Эти правила определяют, должны ли одинаковые URL с разными параметрами сохраняться в кэше браузера как отдельные записи.

Это позволяет браузеру повторно использовать существующие ресурсы, несмотря на различия в параметрах URL, и избегать затрат на повторную загрузку ресурса, если будет возвращено то же содержимое.

Синтаксис

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.

Описание

Связь с API правил спекулятивной загрузки

API правил спекулятивной загрузки поддерживает использование заголовка No-Vary-Search для повторного использования уже предварительно загруженной или предварительно отрисованной страницы с другими параметрами URL — если они перечислены в заголовке No-Vary-Search.

API правил спекулятивной загрузки также может включать поле expects_no_vary_search, указывающее браузеру ожидаемое значение No-Vary-Search (если оно есть) для документов, для которых через правила спекулятивной загрузки отправляются запросы на предварительную загрузку или предварительную отрисовку. Браузер может использовать это значение, чтобы заранее определить, целесообразнее ли дождаться завершения уже выполняющейся предварительной загрузки или отрисовки либо начать новый запрос при совпадении с правилом спекулятивной загрузки. Объяснение приведено в примере «expects_no_vary_search».

Примеры

Разрешение сопоставлять ответы для URL с параметрами в разном порядке с одной записью кэша

Например, если у вас есть страница поиска, которая хранит критерии поиска в параметрах URL, и вы не можете гарантировать, что параметры будут добавляться в URL каждый раз в одном и том же порядке, можно разрешить сопоставлять ответы для URL, отличающихся только порядком параметров, с одной записью кэша с помощью key-order:

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 следует кэшировать отдельно.
• Если этот параметр выделяет указанного пользователя на той же странице и, возможно, открывает выдвижную панель с его данными, браузеру лучше использовать кэшированный ответ для /users. Это может повысить производительность при загрузке страниц пользователей.

Если ваше приложение работает так, как описано во втором примере выше, можно указать заголовок No-Vary-Search, чтобы /users и /users?id=345 считались идентичными для целей кэширования:

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

Разрешение сопоставлять ответы для URL с несколькими разными параметрами с одной записью кэша

Предположим, что в 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")

Спецификации

Совместимость с браузерами

См. также

• Кэширование HTTP: Vary и заголовок Vary