RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

13.1.3. Механизмы управления кэшем

Основные механизмы кэша в HTTP/1.1 (определенные сервером времена expiration и объекты для проверки правильности) являются неявными директивами к кэшам. В некоторых случаях, сервер или клиент, возможно, должны предоставить явные директивы кэшам HTTP. Мы используем заголовок Cache-Control с этой целью.

Заголовок Cache-Control позволяет клиенту или серверу передавать множество директив или в запросах или в ответах. Эти директивы обычно отменяют значение по умолчанию, кэширующее алгоритмы. Как правило, если есть какой-нибудь очевидный конфликт между значениями заголовка, самая ограничительная интерпретация должна быть применена (то есть, тот, который, наиболее вероятно, сохранит семантическую прозрачность). Однако, в некоторых случаях, директивы Cache-Control явно указаны как ослабление приближения семантической прозрачности (например, "max-stale" или "public").

Директивы Cache-Control описаны подробно в разделе 14.9.

13.1.4. Явные предупреждения User Agent

Много пользовательских агентов позволяют пользователям отменить основные кэширующие механизмы. Например, user agent может позволить пользователю определять, который кэшировал объекты (даже явно устарелые) никогда не утверждаются. Или user agent мог бы обычно добавлять "Cache-Control: max-stale =3600" к каждому запросу. Пользователю придется явно запросить или непрозрачное поведение, или поведение, которое заканчивается неправильно неэффективным кэшированием.

Если пользователь отменил основные кэширующие механизмы, user agent должен явно указать для пользователя всякий раз, когда это заканчивается дисплеем информации, которая не могла бы ответить требованиям прозрачности сервера (в частности если отображенный объект, как известно, является устарелым). Так как протокол обычно позволяет user agent определять, являются ли ответы устарелыми или нет, эта индикация должны только быть отображенными, когда это фактически случается. Индикация не диалоговое окно; он мог быть значок (например, изображение гниющей рыбы) или некоторый другой визуальный индикатор.

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

2007 - 2017 © Русские переводы RFC, IETF, ISOC.