Поле Cache-Control

Поле общего заголовка Cache-Control используется для спецификации директив, которые должны исполняться всеми механизмами кэширования вдоль цепочки запрос/отклик. Директивы определяют поведение, которое, как предполагается, должно предотвратить нежелательную интерференцию откликов или запросов в кэше. Эти директивы обычно переписывают алгоритм кэширования, используемый по умолчанию. Директивы кэша являются однонаправленными: присутствие директивы в запросе не предполагает, что та же директива будет присутствовать и в отклике.

Заметьте, что кэши HTTP/1.0 могут не реализовывать управление (Cache-Control), а только использовать директиву Pragma: no-cache.

Директивы кэша должны пропускаться через приложения прокси или внешнего шлюза (gateway), вне зависимости от их значения для этого приложения, так как директивы могут быть применимы для всех получателей в цепочке запрос/отклик. Невозможно специфицировать директивы для отдельных кэшей.

Cache-Control = "Cache-Control" ":" 1#cache-directive cache-directive = cache-request-directive cache-request-directive | cache-response-directive = "nocash" ["=" <">1#field-name<">] | "no-store" | "max-age" "=" delta-seconds | "max-stale" [ "=" delta-seconds ] | "min-fresh" "=" delta-seconds | "only-if-cached" | cache-extension cache-response-directive = "public" | "private" [ "=" <"> 1#field-name <"> ] | "no-cache" [ "=" <"> 1#field-name <"> ] | "no-store" | "no-transform" | "must-revalidate" | "max-age" "=" delta-seconds | cache-extension; cache-extension = token [ "=" ( token | quoted-string ) ]

Если директива появляется без какого-либо параметра 1#field-name, она воздействует на весь запрос или отклик. Когда такая директива приходит с параметром 1#field-name, она воздействует только на именованное поле или поля и не имеет никакого действия на остальную часть запроса или отклика. Этот механизм поддерживает расширяемость. Реализации будущих версий протокола HTTP могут использовать эти директивы для полей заголовка, не определенных в HTTP/1.1.

Директивы управления кэшем могут быть разделены на следующие категории.

• Ограничения на то, что можно кэшировать. Они налагаются только исходным сервером.

• Ограничения на то, что можно записывать в память кэша; определяются исходным сервером или агентом пользователя.

• Модификации базового механизма контроля годности записей вносятся либо исходным сервером, либо агентом пользователя.

• Управление процессом перепроверки годности записей и перезагрузкой осуществляется только агентом пользователя.

• Управление преобразованием объектов.

• Расширения системы кэширования.

Что допускает кэширование?

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

public

Указывает, что отклик может кэшироваться любым кэшем, даже если он в норме не кэшируем или кэшируем только в кэшах индивидуального пользования.

private

Указывает, что все сообщение отклика или его часть предназначена для одного пользователя и не должна быть записана кэшем коллективного пользования. Это позволяет исходному серверу заявить о том, что специфицированные части отклика предназначены только для одного пользователя и он не может отсылаться в ответ на запросы других пользователей. Частный кэш может кэшировать такие отклики.

Использование слова "частный" (private) определяет только возможность кэширования и не гарантирует конфиденциальности для содержимого сообщения. Платные серверы должны принимать дополнительные меры безопасности, например, шифрование

no-cache

Указывает, что все сообщение­отклик или или его фрагмент не должны кэшироваться где бы то ни было. Это позволяет исходному серверу предотвратить кэширование даже для кэшей, сконфигурированных для рассылки устаревших откликов.

Большинство кэшей HTTP/1.0 не распознают и не исполняют директиву no-cache.