Кратко

  • RFC 9111 рекомендует помещать no-store в ответ вместе с must-understand. Кеш, не знающий новой директивы, проигнорирует её, но всё равно получит понятное консервативное указание.
  • Понимание статуса — не чтение трёх цифр и не разбор имени директивы. Кеш должен распознать код и реализовать всё предписанное ему поведение, относящееся к кешированию.
  • Условное игнорирование no-store убирает только один запрет. Правила метода, авторизации, общего кеша, сохраняемости, свежести и повторного использования остаются; гарантии конфиденциальности не возникают.

Один ответ для двух поколений

Представим два кеша, получивших Cache-Control: must-understand, no-store.

Первый был выпущен до появления must-understand. Правило расширения Cache-Control требует игнорировать неизвестные директивы. Поэтому он пропускает первую, узнаёт no-store и не сохраняет ответ.

Второй реализует новую директиву. Этого недостаточно для разрешения. Он обязан распознавать код состояния ответа и выполнять все требования кеширования из определения этого кода. Только тогда RFC 9111 рекомендует ему проигнорировать сопровождающий no-store. После этого ещё предстоит проверить остальные условия сохранения.

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

Смысл теряется, если руководство цитирует только must-understand. Название похоже на универсальный приказ, хотя кеш без реализации обязан его игнорировать. Без no-store исчезает предназначенный старому участнику путь отступления. Единица внедрения — пара, а условие нового поведения — реализованная семантика, не найденная строка.

Распознать — ещё не понять

RFC 9111 даёт операционное определение понимания: кеш распознаёт код состояния и реализует всё указанное для него поведение, связанное с кешированием.

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

Различие видно в документах. RFC 6585 запрещает кешу сохранять ответы 428, 429, 431 и 511. RFC 7538, напротив, определяет 308 Permanent Redirect как кешируемый по умолчанию, если семантика метода или явные средства управления не требуют иного. Это не полный перечень, а иллюстрация того, что статусы ведут к разным решениям.

Продукт, который правильно подписывает 429 как Too Many Requests, но сохраняет его как обычный ответ, распознаёт код, не понимая его в смысле RFC 9111. Тест, проверяющий только разбор must-understand, также измеряет синтаксис, а не соответствие.

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

Старый запрет делает новый путь безопасным

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

Здесь старый тормоз — no-store. Он не противоречит must-understand, а задаёт безопасный вариант по умолчанию. Квалифицированный кеш знает узкое условие, при котором тормоз можно снять.

Пропуск меняет результат. Получив один must-understand, старый кеш игнорирует единственный новый сигнал. Возможно, другая норма всё равно помешает сохранению, но переходный механизм уже не дал ему консервативной инструкции.

RFC 9111 использует SHOULD и для добавления no-store, и для его игнорирования при выполнении условий. Это сильная нормативная рекомендация, а не безусловный приказ и не украшение. Отклонение требует технического объяснения поведения старых участников.

Снятие одного запрета не разрешает всё

«Игнорировать no-store» не означает «сохранить». Исключение удаляет ровно одно препятствие.

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

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

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

Реестр — координата, не сертификат программы

IANA ведёт отдельные реестры директив кеша и кодов состояния HTTP. Они дают общие названия и ссылки на определяющие документы. Они не удостоверяют конкретную установку.

Наличие must-understand в таблице не доказывает поддержку двоичным файлом. Регистрация статуса не означает, что кеш применяет его правила. Успешный тест одного кода нельзя автоматически распространить на будущий.

Способности нужен небольшой пакет доказательств: версии движка и модуля, использованное определение, проверенные требования и результаты. Директива создаёт совместимую точку ветвления, но не производит эти доказательства.

История изменений RFC 9111 поясняет: must-understand введён, чтобы кешам не приходилось понимать семантику новых статусов, если директива отсутствует. Сервер может сообщить, что особые правила важны именно здесь. Он не может удалённо объявить неизвестный кеш компетентным.

Это не печать конфиденциальности

RFC 9111 предупреждает: no-store не является надёжным или достаточным средством приватности. Злонамеренный либо скомпрометированный кеш может не подчиниться, а сеть может допускать перехват. Пара директив не расширяет это обещание.

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

В этой работе не тестировались продукты, не измерялись распространённость, утечки или происшествия. Все сценарии выведены из открытых спецификаций.

Источники и граница доказательств

Реестры и исправления отражают состояние на дату исследования. Источники подтверждают семантику и выводы о модели управления, но не всеобщую поддержку в продуктах.