Кратко

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

Сначала приходит /record?id=54&utm_source=mail, затем /record?utm_source=partner&id=54. Приложение знает, что источник кампании не меняет запись, а порядок ключей не важен. Кэш видит разные целевые URI. Он не вправе выводить их равенство из совпавших тел или названия параметра: это передало бы семантическую власть слою, который хуже всех знает приложение.

draft-ietf-httpbis-no-vary-search-09 от 17 августа 2026 года предлагает явное описание. На 29 августа это активный Internet-Draft рабочей группы HTTPBIS, рассчитанный на Proposed Standard и одобренный IESG в ожидании объявления с последующим контролем Area Director. Это ещё не RFC; поля No-Vary-Search пока нет и в реестре имён полей HTTP IANA.

Текущую редакцию можно испытывать, но нельзя выдавать за неизменный стандарт. Документ подтверждает предлагаемую грамматику и границы. Он не подтверждает реализацию конкретным CDN, правильность классификации или безопасность наблюдаемого hit rate.

Точное разделение остаётся основой

RFC 9111 разрешает повторно использовать сохранённый ответ, когда совпадают метод и целевой URI, поля из Vary, а свежесть либо валидация и директивы кэширования допускают это. Иная строка запроса обычно образует иной URI.

HTTP не знает, является ли user, token или campaign украшением. Имя ключа и несколько одинаковых тел не доказывают, что он не участвует в маршрутизации, разрешении, учёте или будущем варианте ответа.

Новое поле меняет только сопоставление URI. Оно не освежает устаревшее, не отменяет Vary, не превращает private-ответ в общий и не выдаёт право доступа. После признания запросов эквивалентными все прочие проверки RFC 9111 сохраняются.

Малый словарь распределяет полномочия

Значение — Dictionary из RFC 9651. Boolean key-order описывает значимость порядка. params перечисляет игнорируемые имена; except задаёт обратную политику, оставляя различающими только перечисленные ключи. Вместе params и except недопустимы.

Поле задаёт источник, поскольку он владеет семантикой приложения. Посредник не должен добавлять, удалять или менять его, кроме случая, когда сам выступает источником этого ответа. CDN-правило, выведенное из трафика, поменяло бы исполнение знания на самостоятельное определение идентичности.

Ошибка закрывает сопоставление. Отсутствующее, неверное или противоречивое значение возвращает точный запрос и чувствительность к порядку. Теряются hits, а не изоляция. Неизвестные ключи Dictionary игнорируются, поэтому будущие расширения могут только расширять эквивалентность. Ограничение потребует нового поля, иначе старые реализации будут повторно использовать слишком широко.

Сравниваются разобранные пары

Эквивалентность не пересекает scheme, host, port или path. Внутри этой границы нестандартная конфигурация разбирает запрос по модели WHATWG application/x-www-form-urlencoded, удаляет игнорируемые пары либо сохраняет except, при необходимости сортирует по ключу и сравнивает ключи и значения с сохранением дублей.

Percent decoding, превращение + в пробел и обработка пустых частей могут свести разные на вид строки. Неверный UTF-8 может стать U+FFFD, объединив разные байты в один ключ. Unicode-нормализации нет, поэтому формы NFC и NFD остаются различными.

Если подпись относится к исходным байтам, маршрутизатор учитывает порядок дублей или пустое значение означает согласие, различие критично. Draft называет поле бесполезным для запросов вне form-urlencoded. RFC 6943 описывает общий риск сравнения идентификаторов по разным правилам; здесь false positive выбирает фактически доставляемое тело.

Объявление не приказывает кэшу

Поддерживающий кэш может применить расширенное сопоставление, но не обязан. Он вправе сначала искать точный ключ, строить упрощённый индекс или отказаться от кандидата. Источник предоставляет знание; кэш сохраняет локальный выбор, потому что несёт последствие повторного использования.

Если ответы для одного host и path содержат конфликтующие непустые конфигурации, draft разрешает предпочесть связанную с более новым Date, чтобы сходиться к новой политике. Новизна не доказывает правильность. Ошибочная политика тоже бывает последней, а постепенный rollout распределяет её неравномерно.

Инвалидация RFC 9111 не расширяется автоматически. После изменения состояния кэш может инвалидировать эквивалентные URI, но не обязан. Записи, объединённые при чтении, могут сохраниться по-разному после записи. Query cache-buster также перестаёт работать, если его ключ объявлен незначимым; content-addressed path остаётся отдельным и более явным решением.

Идентификаторы продолжают передаваться

Браузер показывает полный URL и может оставить его в истории. CDN и proxy получают параметры, журналы и аналитика могут их сохранить. No-Vary-Search меняет cache matching, а не выполняет очистку, перенаправление или canonicalization.

Private cache иногда не отправит повторную метку источнику. Shared cache всё равно видит запрос и при ошибке расширяет круг получателей одного сохранённого ответа. Нельзя игнорировать ключи, управляющие идентичностью, авторизацией, подписями, согласием, маршрутизацией, аудитом, оплатой, отзывом или иной частью безопасного использования.

Одинаковые пиксели не означают одинаковое право их получить. В худшем случае Alice получает представление, извлечённое для Bob. private, partitioning и корректные controls остаются защитой, но не оправдывают ложную декларацию.

Нужны следы запроса, не дошедшего до источника

Доказательство связывает видимый URL, URL сохранённого ответа и сырое поле, разобранную конфигурацию, преобразованные пары, выбранную запись, остальные проверки RFC 9111, контекст пользователя и partition, origin bypass и fingerprint выданного тела. Один hit rate не отличает правильную абстракцию от эффективной утечки.

Идея Lu Heng о минимальной общей спецификации и локальном будущем решении точно распределяет роли: общими остаются словарь и сравнение, значение ключей определяет приложение, принятие остаётся добровольным для каждого кэша. Приоритет работающего кода требует проверять реальный выбор и результат, а не только конфигурацию.

Различаются и технический и практический суверенитет данных. Источник формально управляет полем, браузер хранит URL, CDN — журнал, кэш — тело; второй запрос источник может вообще не увидеть. Управление должно следовать этой реальной опеке.

При сомнении безопасен лишний miss. Сокращение пользовательской изоляции безопасным исходом быть не может.