Какие коды состояния HTTP можно кэшировать?

Короткий ответ

Согласно RFC 7231, текущему справочнику по содержанию и семантике протокола HTTP / 1.1, следующие коды состояния HTTP определены как кэшируемые, если иное не указано методом определение или явные элементы управления кешем:

• 200 ОК
• 203 Неавторизованная информация
• 204 Нет содержимого
• 206 Частичное содержание
• 300 Несколько вариантов
• 301 Перемещено навсегда
• 404 Not Found
• 405 Метод запрещен
• 410 Gone
• 414 URI слишком длинный
• 501 Не реализовано

Длинный ответ

В RFC 7231 говорится следующее относительно кодов состояния HTTP, которые по умолчанию кэшируются:

6.1. Обзор кодов статуса

[...] Ответы с кодами состояния, которые определены как кэшируемые по умолчанию (например, 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 и 501 в этой спецификации) могут быть повторно использованы кеш с эвристическим истечением срока, если иное не указано в определении метода или явные элементы управления кешем; все остальные коды состояния по умолчанию не кэшируются. [...]

Как только коды состояния HTTP становятся расширяемыми, получатель должен отметить кеширование ответа с нераспознанным кодом состояния:

6. Коды статуса ответа

Элемент status-code - это трехзначный целочисленный код, дающий результат попытки понять и удовлетворить запрос.

Коды состояния HTTP являются расширяемыми. От клиентов HTTP не требуется понимать значение всех зарегистрированных кодов состояния, хотя такое понимание, очевидно, желательно. Однако клиент ДОЛЖЕН понимать класс любого кода состояния, обозначенного первой цифрой, и рассматривать нераспознанный код состояния как эквивалентный коду состояния x00 этого класса, за исключением того, что получатель НЕ ДОЛЖЕН кэшировать ответ с нераспознанный код состояния. [...]

Кеш также зависит от метода HTTP:

4.2.3. Кешируемые методы

Методы запроса могут быть определены как «кэшируемые», чтобы указать, что ответы на них могут быть сохранены для повторного использования в будущем. Как правило, безопасные методы, не зависящие от текущего или авторитетного ответа, определяются как кэшируемые; эта спецификация определяет GET, HEAD и POST как кэшируемые, хотя подавляющее большинство реализаций кеширования поддерживают только GET и HEAD.

Что касается метода POST, есть важная деталь:

4.3.3. POST

[...] Ответы на POST запросы кэшируются, только если они содержат явную информацию о свежести [...]

Дополнительные сведения см. В определении каждого метода.

Дополнительные ресурсы

• RFC 7234: справочник по кэшированию в протоколе HTTP / 1.1
• Проверьте, какие браузеры хранят в своем кеше

Согласно RFC7234 также разрешено кэшировать ответы, доставляющие код, отличный от 200 ( OK):

[...] Наиболее распространенная форма записи в кэш - это успешный результат запроса на извлечение: то есть ответ 200 (OK) на запрос GET, который содержит представление ресурса, идентифицированного целью запроса (раздел 4.3. 1 из [RFC7231]). Однако также возможно кэшировать постоянные перенаправления, отрицательные результаты (например, 404 (не найдено)), неполные результаты (например, 206 (частичное содержимое)) и ответы на методы, отличные от GET, если определение метода допускает такое кеширование и определяет что-то подходящее для использования в качестве ключа кеша.

Так что разработчик браузера решает, что он хочет кэшировать, а что нет.