Кратко

  • Cache-Status выстраивает сообщения кэшей от ближайшего к источнику до ближайшего к пользователю и может различать локальное попадание, причину пересылки, статус следующего узла, остаток свежести, хранение и объединение запросов.
  • Каждый кэш сам решает, когда выдавать поле и какие необязательные параметры раскрывать. hit возможен для устаревшего ответа, TTL рассчитывается локально, а правильная структура списка не удостоверяет авторов и полноту пути.
  • Надёжная эксплуатация сохраняет исходное поле, сопоставляет его с Cache-Control, Age, Via, трассировкой, внутренними событиями и проверкой пользователя, не смешивая доставку, объяснение, атрибуцию и объявление восстановления.

Одна строка, которая слишком быстро стала причиной

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

Cache-Status: Edge; hit; ttl=150

Ситуация кажется простой: Edge отдал объект из кэша, осталось две с половиной минуты, значит достаточно purge или ожидания. Но RFC 9211 определяет hit уже: этот кэш не пересылал данный запрос и получил ответ из своего хранилища. Устаревший ответ тоже может быть попаданием, если его разрешено использовать без пересылки. TTL — остаток свежести по вычислению этого кэша, включая возможную эвристику и локальную политику.

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

Общая грамматика вместо словаря поставщика

Кэши давно добавляли диагностические заголовки: HIT, MISS, коды памяти, имена узлов и счётчики. Собирать их было легко, сравнивать — трудно: смысл оставался внутри продукта.

Cache-Status использует HTTP Structured Fields и представляет значение списком. Каждый элемент соответствует кэшу, обработавшему запрос. Первый ближе всего к источнику, последний — к пользователю. Reverse proxy может записать первый элемент, shield сохранить его и добавить свой, edge продолжить цепочку.

Структура показывает многоуровневые решения: попадание внутри при uri-miss снаружи, валидацию, объединение запросов и сохранение результата. Независимый инструмент получает предсказуемые типы вместо набора частных кодов.

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

Имя элемента ещё не удостоверенная личность

Идентификатор может быть названием продукта, сервиса, хоста, IP-адресом или сгенерированной строкой. Такая гибкость подходит разным архитектурам и скрывает топологию, но не привязывает Edge-Moscow к конкретной машине, компании или площадке.

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

Обычно удобно, когда CDN доставляет байты и одновременно объясняет доставку. В тяжёлом инциденте, компрометации или договорном споре тот же контроль над событием и его первым описанием становится риском. Журналы источника, трассы и пользовательские измерения должны сохраняться независимо.

Попадание не означает правильность

hit говорит, что этот запрос был удовлетворён локально без движения к источнику. Ответ 304 или 206, построенный на сохранённом объекте, может остаться попаданием. Объект, который есть в кэше, но требует пересылки из-за устаревания или неполноты, не является hit. Устаревший объект, использованный без пересылки по разрешённому правилу, — может.

Хранение, выбор, повторное использование, проверку и stale serving определяют RFC 9111, Cache-Control, Expires, validators, Vary, директивы запроса и расширения вроде stale-if-error. Cache-Status описывает принятое решение и не выдаёт разрешение.

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

Причина пересылки важнее общего MISS

fwd объясняет движение к источнику. uri-miss означает отсутствие ответа для URI. vary-miss — наличие URI, но отсутствие представления, соответствующего полям запроса и сохранённому Vary. request — наличие свежего кандидата, который семантика запроса не разрешила применить. stale, partial, method и bypass описывают другие пути; miss остаётся менее точным вариантом.

Реакции различаются. Рост URI miss может следовать за сменой путей. Vary miss — за новой языковой или кодировочной осью. request — за клиентами, требующими перепроверки. bypass может доказывать нормальную работу исключения.

Если панель вновь объединяет эти значения в MISS, она уничтожает информацию, которую стандарт сделал переносимой.

Параметры принадлежат разным слоям доказательства

fwd-status показывает код следующего узла. Кэш может перепроверить объект, получить 304 и вернуть клиенту 200. Это свидетельство условного обмена, не правильности бизнес-данных.

ttl — остаток свежести по расчёту кэша около отправки заголовков. Он бывает отрицательным и может учитывать эвристику. Это не универсальное время истечения и не замена Age, оценивающему срок с генерации или проверки на источнике через хранение и транспорт.

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

key передаёт, возможно в частной форме, использованный ключ. Он полезен для query, Vary, языка и изоляции арендаторов, но способен раскрыть преобразования для cache poisoning. detail имеет локальный смысл; одинаковый token у двух продуктов не обязан быть эквивалентным.

Большинство параметров необязательны. Отсутствие — это отсутствие утверждения, не отрицание события. Система, превращающая unknown в false, создаёт вымышленную уверенность.

Управление, статус и путь — разные поверхности

Cache-Control управляет поведением. Age даёт временную оценку. Via показывает промежуточных получателей и протоколы. Proxy-Status шире описывает работу и ошибки proxy. Cache-Status сообщает о решениях кэша. No-Vary-Search может объявлять эквивалентность query-компонентов для ключа.

Последующий hit не доказывает безопасность эквивалентности. Видимый ключ не подтверждает наличие всех измерений персонализации. Положительный TTL не исправляет ошибочную директиву.

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

Встроенной подписи нет

RFC 9211 не определяет подпись или MAC. HTTP Message Signatures могут покрывать выбранные поля, но требуют профиля: обязательных компонентов, ключей, алгоритмов, времени, полномочий подписанта и ошибок.

Cache-Status должен явно войти в покрытие. Нужно также знать точку подписи, поскольку более поздний кэш способен дописать элемент после ранней подписи. Валидная подпись подтверждает связь подписанта с покрытыми компонентами, но не наблюдает память кэша и не доказывает lookup.

Многим услугам достаточно аутентифицированного debug-доступа, контролируемого захвата, общих trace ID и событий в отдельном хранилище. Требуется точное описание реальной гарантии, а не символическое включение криптографии.

Диагностика создаёт канал утечки

RFC 9211 предупреждает: поле помогает исследовать поведение кэша и выводить активность пользователей. Знание хранения может поддержать timing attack, а ключ — показать преобразования для cache poisoning. Простая обфускация не снимает базовый риск.

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

Публичный минимум может содержать стабильные псевдонимы и основное решение. Авторизованный debug — TTL, next-hop, хранение, collapse и безопасный ключ. Чувствительная среда может экспортировать богатые события только во внутреннюю независимую систему.

Зрелое решение избегает как публичного оракула, так и полного молчания, при котором клиент зависит от единственного рассказа поставщика.

Расследование с несколькими свидетелями

Сначала сохраняется сырой ответ: точка и время, метод, URI, значимые поля, статус, Date, Age, Cache-Control, Expires, ETag, Last-Modified, Vary, Via, Proxy-Status и полный порядок Cache-Status.

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

Затем нужна корреляция: hit с lookup и объектом; fwd=stale; fwd-status=304 с условным запросом; collapse с группой и числом ожидающих; stored с событием записи. Наконец, доставленное представление сравнивают с нужным для пользователя, языка и арендатора. HIT, ставший MISS после purge, доказывает лишь смену решения кэша.

Испытания, придающие стандарту рабочий смысл

Создайте известный hit и докажите отсутствие upstream-запроса. Разделите URI и Vary miss. Принудите проверку и различите 304 сверху и финальный статус. Проверьте разрешённый stale и отрицательный TTL. Объедините параллельные miss и сопоставьте ожидающих с нагрузкой источника.

Проверьте раскрытие: никаких чувствительных ключей публично, только одобренные детали в debug, сохранённый порядок после обновлений edge, shield и gateway, неизвестное расширение без выдуманной семантики. Для подписей изменение покрытого компонента должно проваливаться, а Cache-Status — действительно входить в базу.

Реестр IANA Cache-Status координирует имена и типы, а реестр HTTP-полей фиксирует постоянный List. Регистрация доказывает общий язык, не внедрение продукта и не правду конкретного ответа.

Реестр доказательств