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

13.2.4. Вычисление устаревания

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

Мы используем термин "expires_value", чтобы обозначить значение заголовка Expires. Мы используем термин "max_age_value", чтобы обозначить соответствующее значение числа секунд, несшего в соответствии с директивой max-age заголовка Cache-Control в ответе (см. раздел 14.10.

Директива max-age берет приоритет над Expires, так, если max-age присутствует в ответе, вычисление просто:

freshness_lifetime = max_age_value

Иначе, если Expires присутствует в ответе, вычисление:

freshness_lifetime = expires_value - date_value

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

Если ни Expires, ни Cache-Control: max-age появляется в ответе, и ответ не включает другие ограничения на кэширование, кэш МОЖЕТ вычислить время существования свежести, используя эвристику. Если значение больше чем 24 часа, кэш должен прикрепить Warning 13 к любому ответу, возраст которого составляет больше чем 24 часа, если такое предупреждение не было уже добавлено.

Кроме того, если у ответа действительно есть время Last-Modified, эвристическое значение expiration ДОЛЖНО быть не больше, чем некоторой фракцией интервала с этого времени. Типичная установка этой фракции могла бы составить 10 %.

Вычисление, чтобы определить, истек ли ответ, весьма просто:

response_is_fresh = (freshness_lifetime> current_age)
2007 - 2017 © Русские переводы RFC, IETF, ISOC.