В сущности, значение Age - сумма времен которые ответ находился в каждом из кэшей по пути от первоначального сервера и времен его передачи по сети.

Возраст ответа может быть вычислен двумя совершенно независимыми способами:

1. "Сейчас" минус date_value, если локальные часы хорошо синхронизированы с часами первоначального сервера. Если результат отрицателен, результат заменяется нулем.

2. age_value, если все кэши по пути ответа реализуют HTTP/1.1.

При условии, что мы имеем два независимых способа вычисления возраста ответа при его получении, мы можем объединить их как

Corrected_received_age = max("сейчас" - date_value, age_value)

и пока часы у нас синхронизированы, а все кэши на пути ответа - HTTP/1.1, получаем надежный (консервативный) результат.

Эта поправка применяется в каждом HTTP/1.1 кэше по пути следования ответа, так что если на пути встретится HTTP/1.0 кэш, то полученный возраст будет вычислен правильно, если часы этого кэша хорошо синхронизированы.

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

Если запрос, который привел к возвращенному значению Age, должно быть был инициализирован до порождения значений Age, мы можем исправлять наложенные сетью задержки, делая запись времени, когда был сгенерирован запрос. Таким образом, когда получено значение Age, оно должно быть интерпретировано относительно времени, когда был сгенерирован запрос, а не относительно времени, когда был получен ответ. Этот алгоритм приводит к консервативному поведению независимо от того, какова задержка. Вычисляем:

corrected_initial_age = corrected_received_age + ("сейчас" - request_time)

Где "request_time" - время (согласно локальным часам), когда был послан запрос, вызвавший данный ответ.

Резюме алгоритма вычисления возраста полученного кэшем ответа:

/* * age_value * - это значение Age: заголовок, полученный кэшем в * этом ответе. * date_value * - это значение Date первоначального сервера: заголовок * request_time * - это (локальное) времея, когда кэш сделал запрос, * который вызвал этот кэшируемый ответ * response_time * - это (локальное) время, когда кэш получил ответ * now * - текущее (локальное) время */ apparent_age = max(0, response_time - date_value); corrected_received_age = max(apparent_age, age_value); response_delay = response_time - request_time; corrected_initial_age = corrected_received_age + response_delay; resident_time = now - response_time; current_age = corrected_initial_age + resident_time;

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

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

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

Термин "expires_value" представляет значение заголовка Expires. Термин "max_age_value" применяется для указания значения числа секунд, представленного директивой max-age заголовка Cache-Control ответа.

Директива 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, то эвристическому значению времени устаревания следует принимать значение не более некоторой части временного интервала, прошедшего этого времени. Типичная значение этой части могло бы быть 10%.

Вычислить, истек ли ответ, совершенно просто:

response_is_fresh = (freshness_lifetime > current_age)

13.2.5 Устранение противоречий в значениях устаревания.

В том случае, когда значения устаревания назначены оптимистично, возможен случай, когда два кэша содержат различные значения свежести одного и того же ресурса.

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

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

13.2.6 Устранение противоречий между несколькими ответами.

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

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

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

Cache-Control: max-age=0

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

Cache-Control: no-cache