Кратко

  • Кеш с поддержкой целевых полей выбирает первое допустимое непустое поле из упорядоченного списка целей; кеш, не считающий поле целевым, не должен менять из-за него своё поведение.
  • Поэтому один и тот же ответ на разных переходах может быть сохранён, отклонён или подчинён другому полю, даже если CDN-Cache-Control синтаксически верен.

Рассмотрим заведомо гипотетический запуск. Источник отправляет Cache-Control: no-store и CDN-Cache-Control: max-age=600. Первая CDN распознаёт целевое поле и хранит ответ десять минут. Следующий корпоративный кеш не включает поле в список целей и выполняет no-store. Другая CDN ставит собственное поле поставщика выше CDN-Cache-Control и выбирает его. Однако панель фиксирует один итог: «политика кеша — 600 секунд».

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

RFC 9213 определяет целевые поля управления кешем как поля ответа, отдельное имя которых указывает на нужный кеш или класс кешей. CDN-Cache-Control — стандартный пример. Значение использует семантику директив кеширования, а реализующий стандарт кеш ведёт упорядоченный список целей. Он может быть фиксированным, настраиваемым или формироваться для отдельного запроса. При нескольких известных полях кеш выбирает первое допустимое и непустое по порядку списка.

У выбора есть сильное последствие. После него кеш определяет политику ответа по целевому полю и игнорирует обычные Cache-Control и Expires для этого ответа. Если в списке нет допустимого непустого поля, кеш возвращается к обычным механизмам HTTP из RFC 9111. Поэтому два соответствующих стандарту кеша могут получить одинаковые байты и принять разные решения из-за различия списков.

Область действия столь же важна, как приоритет. Поле, отсутствующее в списке целей кеша, не должно менять его поведение и должно пересылаться дальше. Кеш вне CDN может увидеть CDN-Cache-Control, но не применять его. CDN, использующая поле, обычно передаёт его последующим CDN, однако RFC 9213 разрешает удаление, если передача нежелательна. Поле в одной точке наблюдения не доказывает, какой набор получили все предыдущие и следующие узлы.

Разбор создаёт ещё одну границу. Целевые поля являются словарями Structured Fields. Они часто похожи на Cache-Control, но обработка ошибок различается. Пустое или недопустимое поле игнорируется, что может включить резервную политику. Если панель записывает строку без результата парсера, она способна приписать поведение полю, которое кеш не принял.

Свежесть также относительна к кешу, выбравшему политику. В примере RFC 9213 CDN может считать ответ свежим 3600 секунд, другие общие кеши — 600, а остальные — 60 секунд. Через 1800 секунд ответ свеж для CDN и устарел в других местах. Противоречия нет: действуют разные политики. Ошибка состоит в сведении их к единому состоянию всей цепочки.

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

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

Эта запись — редакционный операционный контроль, а не протокольный объект IETF. Она не позволяет превратить допустимое поле в недоказанное утверждение обо всей цепочке.

Источники