Кратко

  • Cache-Control: only-if-cached требует только сохранённый ответ; соблюдающий директиву кэш должен вернуть подходящий ответ либо 504.
  • Такой 504 может быть создан без связи с сервером-источником, поэтому он доказывает неудачу локального поиска, а не недоступность исходного сервера.

Представим заведомо гипотетический мониторинг доступности. Оператор хочет проверить, находится ли снимок конфигурации на периферии, и отправляет GET с Cache-Control: only-if-cached. Кэш не находит сохранённого ответа, удовлетворяющего условиям, и возвращает 504. Правило видит только статус, объявляет тайм-аут сервера-источника и вызывает его команду. Однако кэш выполнил указание: не пересылал запрос, а сервер-источник ничего не получил.

Неоднозначность возникает из общего и специального контекста. RFC 9110 обычно определяет Gateway Timeout как отсутствие своевременного ответа от вышестоящего сервера, к которому шлюз должен был обратиться. RFC 9111 оставляет кэшу, соблюдающему only-if-cached, два результата: совместимый с остальными ограничениями сохранённый ответ или 504. Во второй ветви клиент сам потребовал не обращаться выше.

Директива меняет вопрос эксперимента. Она спрашивает не «может ли сервер-источник ответить», а «может ли этот кэш выполнить запрос только сохранённым ответом, который разрешено использовать». Интерпретация как сквозной проверки смешивает два пути управления.

Наличия байтов недостаточно. Должны совпадать цель и метод, названные Vary поля, требования проверки; ответ должен быть свежим, успешно проверенным или разрешённым к выдаче устаревшим. В кэше могут быть данные для URI, но не быть подходящего кандидата. Значение 504 может быть «ничего пригодного при этих условиях», а не «ничего не сохранено».

Статус также не называет кэш, принявший решение. Запрос может пройти через браузер, корпоративный прокси, CDN и шлюз. Нужны идентификатор ответившего узла, увиденная им директива, кандидаты и причины отклонения, а также факт запрета пересылки. Без этого панель назначает причину по привычке.

Сбой сервера-источника и отсутствие пригодной копии на периферии имеют разных владельцев, способы исправления и последствия. Успех обычного зонда рядом с cache-only не обязательно означает нестабильность: зонды задают разные вопросы.

Ведите протокол решения для cache-only. Это предложенный редакционный контроль, а не объект протокола IETF. Свяжите цель, метод, директивы, идентификатор и ключ кэша, кандидаты, сравнение Vary, свежесть или право устаревшей выдачи, проверку, выбор или промах, решение о пересылке и сведения о попытке обращения к вышестоящему серверу. Затем классифицируйте результат как пригодность кэша, политику пересылки или тайм-аут сервера-источника.

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

Источники