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

13.2. Модель устаревания

13.2.1. Устаревание, определеяемое сервером

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

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

Механизм expiration применяется только к ответам, взятым от кэша а не к непосредственным ответам, отправленным немедленно клиенту запроса.

Если сервер происхождения желает вынудить семантически прозрачный кэш проверить достоверность каждого запроса, он может назначить явное время expiration в прошлом. Это означает, что ответ является всегда устарелым, и таким образом кэш ДОЛЖЕН проверить достоверность его перед использованием него для последующих запросов. См. раздел 14.9.4 для более ограничительного способа вызвать придание вновь юридической силы.

Если сервер происхождения желает вызвать какой-нибудь HTTP/1.1 кэш, независимо от того как он конфигурирован, проверить достоверность каждого запроса, он должен использовать "must-revalidate" директива Cache-Control (см. раздел 14.9).

Серверы определяют явные времена expiration или, используя заголовок Expires, или, используя директиву max-age заголовка Cache-Control.

Время expiration не может использоваться, чтобы вынудить user agent обновить свой дисплей или перезагрузить ресурс; его семантика применяется только к кэшированию механизмов, и такие механизмы должны только проверить состояние expiration ресурса, когда новый запрос на тот ресурс инициализирован. См. раздел 13.13 для объяснения различия между механизмами хронологии и кэшами.

13.2.2. Эвристическое устаревание

Так как серверы происхождения не всегда предоставляют явные времена expiration, кэши HTTP обычно назначают эвристические времена expiration, используя алгоритмы, которые используют другие значения заголовка (например, время Last-Modified), чтобы оценить вероятное время expiration. HTTP/1.1 спецификация не предоставляет специфичные алгоритмы, но действительно налагает ограничения самого плохого случая на их результаты. Так как эвристические времена expiration могут поставить под угрозу семантическую прозрачность, они должны использоваться осторожно, и мы поощряем серверы происхождения предоставлять явные времена expiration в максимально возможной степени.

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