Кратко

  • RFC 5861, опубликованный в мае 2010 года как независимый информационный документ, определил stale-while-revalidate для старого ответа во время фоновой проверки и stale-if-error для старого ответа при серверной ошибке.
  • Его примеры разделяют часы. max-age=600, stale-while-revalidate=30 даёт десять минут свежести и ещё 30 секунд; max-age=600, stale-if-error=1200 может при возрасте 900 секунд заменить ошибку 500 сохранённым 200 с Age: 900.
  • RFC 9111 от июня 2022 года сохранил требование разрешения на старые ответы и объявил прежнее поле Warning устаревшим.

Старый ответ приходит раньше проверки

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

При Cache-Control: max-age=600, stale-while-revalidate=30 ответ свеж 600 секунд. В следующие 30 секунд кеш может немедленно отдать стареющую копию и параллельно запросить подтверждение у источника. Читатель минует задержку, а проверка готовит решение для следующего читателя. Издатель заранее согласился на короткое отставание видимых правок.

Окно заканчивается даже тогда, когда за эти 30 секунд никто не запросил страницу и проверка не началась. Если результат проверки не получен, следующая заявка ждёт обычной обработки. Для редкой страницы ускорение может вовсе не проявиться. Длина окна и частота обращений определяют, сколько читателей пройдут без ожидания. Копия остаётся старой, даже когда ей позволено говорить первой.

Ошибка источника за успешным статусом

stale-if-error включается по другой причине. Кеш пытается получить актуальный ответ и встречает условие, ведущее к 500, 502, 503 или 504. Пока возраст сохранённой копии укладывается в опубликованный предел, кеш может выдать её вместо ошибки. Клиент получает прежний успешный результат в момент нынешнего отказа источника.

Пример RFC задаёт max-age=600, stale-if-error=1200. При возрасте 900 секунд проверка получает 500. Кеш вправе послать сохранённый 200 OK с Age: 900. Статус говорит об отданном теле, а Age показывает, сколько времени прошло с создания или успешной проверки у источника. Нынешняя ошибка сервера скрыта от читателя в пределах разрешённого срока.

Дополнительные 1 200 секунд идут после 600 секунд свежести. Когда суммарный возраст в примере превышает 1 800 секунд, ошибка должна пройти до клиента. Архивная страница может пережить двадцать минут со старой версией лучше, чем краткий сбой. Сведения о доступе, цене или переводе денег могут стать опасными намного быстрее. Предел старения должен следовать смыслу ресурса.

Фоновая проверка и ошибка дают разные основания. stale-while-revalidate экономит время ожидания, пока источник ещё способен подтвердить данные. stale-if-error поддерживает доступность, когда подтверждение не удалось. Разные условия заслуживают разных часов. Оператор источника публикует границы, а кеш решает, использовать ли разрешение при конкретном запросе.

Предупреждение исчезло из правил

В тексте 2010 года старый ответ должен был нести ненулевой Age и поле Warning по правилам того времени. RFC 9111 в 2022 году упразднил Warning: его редко создавали и ещё реже показывали людям. Age остался оценкой времени после создания ответа или его последней успешной проверки у источника. Современный успешный статус сам по себе не показывает, что за ним стояла старая копия.

Документ 2022 года жёстко ограничивает посредника. Если no-cache, must-revalidate или другое применимое указание запрещает старый ответ, кеш не может его послать. В остальных случаях нужны отключение от источника, прямое разрешение клиента или источника либо внешнее соглашение. Расширения RFC 5861 названы примером прямого разрешения. Кеш управляет выдачей внутри отведённой полосы, а не устанавливает свои сроки для всего хранимого мира.

Независимый информационный RFC 2010 года получил место в объяснении разрешённой устарелости стандартного RFC 2022 года. Эта запись не измеряет внедрение. Для него нужны датированные заголовки ответов, настройки кешей и захваты трафика во время сбоев. Нормативная цепочка уже показывает сделку: источник разрешает ограниченный возраст, кеш покупает за него скорость или устойчивость, читатель принимает более раннее состояние информации.