Управление перепроверкой пригодности и перезагрузкой

Иногда агент пользователя может потребовать, чтобы кэш перепроверил пригодность своих записей с помощью исходного сервера (а не соседнего кэша по пути к исходному серверу) или перезагрузил свой кэш из исходного сервера. Может потребоваться перепроверка Endtoend, если и кэш, и исходный сервер имеют завышенные оценки времени жизни кэшированных откликов. Перезагрузка End-to-end может понадобиться, если запись в кэше оказалась по какой­то причине поврежденной.

Перепроверка типа End-to-end может быть запрошена в случае, когда клиент не имеет своей локальной копии (этот вариант мы называем "не специфицированная перепроверка end-to-end") или когда клиент имеет локальную копию (такой вариант называется "специфической перепроверкой end-to-end").

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

End-to-end reload

Запрос включает в себя директиву управления кэшем no-cache или для совместимости с клиентами HTTP/1.0, Pragma: no-cache. В запросе с директивой no-cache может не быть никаких имен полей. Сервер не должен использовать кэшированную копию при ответе на этот запрос.

Specific end-to-end revalidation

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

Unspecified end-to-end revalidation

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

Когда промежуточный кэш вынуждается с помощью директивы max-age=0 перепроверить свои записи, присланный клиентом валидатор может отличаться от того, что записан в данный момент в кэше. В этом случае кэш может воспользоваться в своем запросе любым из валидаторов, не нарушая семантической прозрачности.

Однако выбор валидатора может влиять на результат. Наилучшим подходом для промежуточного кэша является использование в запросе своего собственного валидатора. Если сервер присылает отклик 304 (Not Modified), то кэш должен отправить свою уже проверенную копию клиенту со статусным кодом 200 (OK). Если сервер присылает отклик с новым объектом и валидатором кэша, промежуточный кэш должен сверить, тем не менее, полученный валидатор с тем, что прислал клиент, используя функцию сильного сравнения. Если валидатор клиента равен присланному сервером, то промежуточный кэш просто возвращает код 304 (Not Modified). В противном случае он присылает новый объект со статусным кодом 200 (OK).

Если запрос включает в себя директиву no-cache, в нем не должно быть minfresh, max-stale или maxage.

В некоторых случаях, таких, как периоды исключительно плохой работы сети, клиент может захотеть возвращать только те отклики, которые в данный момент находятся в памяти, и не перезагружать или перепроверять записи из исходного сервера. Для того, чтобы сделать это, клиент может включить в запрос директиву only-if-cached. При получении такой директивы кэшу следует либо реагировать, используя кэшированную запись, которая соответствует остальным требованиям запроса, либо откликаться статусным кодом 504 (Gateway Timeout). Однако если группа кэшей работает как унифицированная система с хорошей внутренней коннективностью, тогда такой запрос может быть переадресован в пределах группы кэшей

Поскольку кэш может быть сконфигурирован так, чтобы игнорировать времена жизни, заданные сервером, а запрос клиента может содержать директиву maxs-tale, протокол включает в себя механизм, который позволяет серверу требовать перепроверки записей в кэше для любого последующего применения. Когда в отклике, полученном кэшем, содержится директива must-revalidate, этот кэш не должен использовать эту запись для откликов на последующие запросы без сверки ее на исходном сервере. Таким образом, кэш должен выполнить перепроверку end-to-end каждый раз, если согласно значениям Expires или maxage кэшированный отклик является устаревшим.

Директива mustrevalidate необходима для поддержания надежной работы для определенных функций протокола. При любых обстоятельствах HTTP/1.1 кэш должен выполнять директиву mustrevalidate. В частности, если кэш по какой­-либо причине не имеет доступа к исходному серверу, он должен генерировать отклик 504 (Gateway Timeout).

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

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

Директива proxyrevalidate имеет то же значение, что и mustrevalidate, за исключением того, что она неприменима для индивидуальных кэшей агентов пользователя. Она может применяться в отклике на подтвержденный запрос, чтобы разрешить кэшу пользователя запомнить и позднее прислать отклик без перепроверки (так как он был уже подтвержден однажды этим пользователем), в то же время прокси должен требовать перепроверки всякий раз при обслуживании разных пользователей (чтобы быть уверенным, что каждый пользователь был авторизован). Заметьте, что такие авторизованные отклики нуждаются также в директиве управления кэшем public, чтобы разрешить их кэширование.