Кратко

  • HTTP Vary называет поля запроса, которые могли повлиять на выбор представления сервером-источником; перед повторным использованием без проверки кеш обязан сопоставить эти поля.
  • Поле не подтверждает фактическую конфигурацию ключа, все критерии приложения, границы арендатора или авторизации и хеш реально выданного представления.

Представим условную платформу, которая раздаёт настройки разных арендаторов по одному URI. Арендатор A запрашивает ресурс, источник возвращает его фирменное оформление и Vary: Accept-Encoding. Панель контроля видит корректное поле Vary и отмечает изоляцию зелёным. Затем арендатор B обращается к тому же URI с тем же предпочтением кодирования и получает с пограничного узла байты A.

Vary не нарушил правила. Поле описало измерение, которое источник объявил для выбора этого ответа. Ошибка состояла в том, что ограниченное заявление приняли за доказательство более широкой границы, которую оно никогда не обещало сертифицировать.

Что действительно означает Vary

RFC 9110 определяет Vary как поле ответа, описывающее части запроса, помимо метода и целевого URI, которые могли повлиять на выбор содержимого источником. Если значение содержит имена полей, они становятся полями выбора. Это заявление источника о возможных входных данных для конкретного ответа.

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

Звёздочка ещё яснее показывает границу. Vary: * означает, что на выбор могли повлиять аспекты вне названных полей, например сетевой адрес клиента. Получатель не может определить пригодность ответа для нового запроса только по полям и должен направить запрос источнику. Прокси не вправе создавать такую звёздочку. Это признание неопределённости, а не универсальный переключатель изоляции.

Фактический ключ кеша — отдельный факт

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

Если сохранённый ответ содержит Vary, кеш не должен использовать его без проверки, пока все названные поля не совпадут с запросом, который привёл к сохранению. Нормализация допустима лишь там, где она сохраняет семантику поля. Отсутствие названного поля совпадает только с отсутствием в следующем запросе. Сохранённый ответ с Vary: * не совпадает никогда.

Это строгие правила, но они не отвечают на четыре эксплуатационных вопроса. Действительно ли развёрнутый кеш разобрал и применил поле? Не удалил ли его посредник? Не выбирало ли приложение содержимое по неназванному условию — например, по контексту арендатора, определённому после аутентификации? Соответствует ли выданный объект варианту, который кеш считал выбранным? Vary относится к доказательствам, но не даёт полного ответа.

Изоляция может зависеть от невидимых измерений

Приложение способно выбирать представление по аутентифицированной учётной записи, сопоставлению арендатора, функциональной группе, версии политики, юрисдикции или версии пограничной конфигурации. Одни факты присутствуют в полях запроса, другие берутся из состояния сервера. Если влияют факторы вне сообщения, RFC 9110 допускает Vary: *, но это запрещает обычное повторное использование, а не описывает пригодный для повторного использования частный раздел.

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

Это также не вопрос свежести. Свежий вариант может быть неверным из-за пропущенного измерения ключа. Устаревший вариант может находиться в правильном разделе. Повторная проверка способна подтвердить пригодность представления по правилам HTTP, но не доказывает попадание запроса в раздел нужного арендатора. Свежесть, проверка, авторизация и выбор варианта связаны, но не тождественны.

Доказательства для обоснованного вывода

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

Предлагаемый здесь «акт выбора варианта» — редакционная модель объединения доказательств, а не элемент протокола IETF. Он не позволяет превратить узкий сигнал стандарта в широкую эксплуатационную гарантию. В нём нужна и точка наблюдения: источник, промежуточный кеш и пограничный узел могут видеть разные поля и применять разные настройки.

Vary полезен именно при соблюдении его границ. Он делает объявленное согласование содержимого видимым и устанавливает конкретные обязанности сопоставления. Ошибка начинается, когда заявление считают доказательством реализации, изоляции или результата. Заголовок может указать задуманные измерения выбора. Только объединённые данные о конфигурации и доставке показывают, что правильное представление осталось по правильную сторону границы.

Источники