Вычисление времени жизни (Expiration)

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

Мы применяем термин expires_value для обозначения содержимого заголовка Expires. Для обозначения числа секунд, определенного директивой максимального возраста заголовка Cache-Control отклика, используется термин max_age_value.

Директива максимального возраста имеет приоритет перед Expires — так, если maxage присутствует в отклике, вычисление производится просто:

freshness_lifetime = max_age_value

В противном случае, если в отклике присутствует Expires, то вычисления осуществляются следующим образом:

freshness_lifetime = expires_value date_value

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

Если ни Expires, ни Cache-Control: maxage не определяют максимальный возраст отклика, а отклик не содержит других ограничений на кэширование, кэш может вычислить время жизни, используя эвристику. Если эта величина больше 24 часов, кэш должен присоединить к отклику Warning 13 (если такое предупреждение еще не добавлено).

Кроме того, если отклик имеет время Last-Modified, эвристическое значение времени жизни должно быть не больше некоторой доли времени, прошедшего со времени модификации. Типичное значение этой доли может составлять 10%. Расчет того, истекло ли время жизни отклика, достаточно прост:

response_is_fresh = (freshness_lifetime > current_age)

Устранение неопределенности значений времени жизни

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

Если клиент, выполняя извлечение ресурса, получает отклик не из первых рук на запрос, который был свежим в своем собственном кэше, а заголовок Date в его кэше новей, чем Date нового отклика, тогда клиент может игнорировать этот отклик. Если это так, он может повторить запрос с директивой "Cache-Control: maxage=0", чтобы усилить контроль со стороны исходного сервера.

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

Неопределенность из-за множественных откликов

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

Ни метка объекта, ни значение времени жизни не могут определять порядок откликов, так как возможно, что более поздний отклик имеет срок годности, который истекает раньше. Однако спецификация HTTP/1.1 требует передачи заголовка Date в каждом отклике, а значения Date должны быть кратны одной секунде.

Когда клиент пытается перепроверить запись в кэше, а отклик, который он получает, содержит заголовок Date, который оказывается старше, чем у другой, уже существующей записи, тогда клиенту следует безусловно повторить запрос и включить

Cache-Control: maxage=0

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

Cache-Control: no-cache

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

Если значения Date равны, тогда клиент может использовать любой отклик (или может, если он особенно осторожен, затребовать новый отклик). Серверы не должны зависеть от возможности клиентов четко выбирать между откликами, сгенерированными в пределах одной и той же секунды, если их сроки пригодности перекрываются.