14.9.4. Перепроверки правильности кэша и средства управления перезагрузкой
Иногда user agent, возможно, хочет или должен настоять, чтобы кэш повторно проверил достоверность своего элемента кэша с сервером происхождения (и не только со следующим кэшем вдоль пути на сервер происхождения), или перезагружать его элемент кэша от сервера происхождения. придание вновь юридической силы End-to-end может быть необходимым, если или кэш или сервер происхождения оценили слишком высоко время expiration кэшируемого ответа. перезагрузка End-to-end может быть необходимой, если элемент кэша стал разрушенным по некоторым причинам.
Придание вновь юридической силы End-to-end можно запросить или когда у клиента нет его собственной локальной кэшируемой копии, когда мы называем его "неопределенным непрерывным приданием вновь юридической силы", или когда у клиента действительно есть локальная кэшируемая копия, когда мы называем его "специфичным непрерывным приданием вновь юридической силы."
Клиент может определить эти три вида действия, используя директивы запроса CacheControl:
- Перезагрузка End-to-end
- Запрос включает "no-cache" директива Cache-Control или, для совместимости с HTTP/1.0 клиенты, "Pragma: no-cache". Никакие имена полей не могут быть включены в директиву no-cache в запросе. Сервер не ДОЛЖЕН использовать кэшируемую копию, отвечая на такой запрос.
- Специфичное непрерывное придание вновь юридической силы
- Запрос включает "max-age =0" директив Cache-Control, которые вынуждают каждый кэш вдоль пути на сервер происхождения повторно проверить достоверность своего собственного элемента, если таковые вообще имеются, со следующим кэшем или сервером. Начальный запрос включает проверяющее достоверность кэша условное выражение в текущий объект для проверки правильности клиента.
- Неопределенное непрерывное придание вновь юридической силы
- Запрос включает "max-age =0" директив Cache-Control, которые вынуждают каждый кэш вдоль пути на сервер происхождения повторно проверить достоверность своего собственного элемента, если таковые вообще имеются, со следующим кэшем или сервером. Начальный запрос не включает проверяющее достоверность кэша условное выражение; первый кэш вдоль пути (если любой), который хранит элемент кэша для этого ресурса, включает проверяющее достоверность кэша условное выражение в его текущий объект для проверки правильности.
Когда промежуточный кэш вызван, посредством max-age =0 директив, повторно проверить достоверность ее собственного элемента кэша, и клиент предоставил ее собственный объект для проверки правильности в запросе, предоставленный объект для проверки правильности может отличаться от объекта для проверки правильности, в настоящий момент сохраненного с элементом кэша. В этом случае, кэш может использовать любой объект для проверки правильности в создании его собственного запроса, не затрагивая семантическую прозрачность.
Однако, вариант объекта для проверки правильности может затронуть производительность. Лучший подход для промежуточного кэша, чтобы использовать его собственный объект для проверки правильности, делая его запрос. Если ответы сервера с 304 (Not Modified), то кэш должен возвратить свою теперь утвержденную копию клиенту с 200 (OK) ответ. Если ответы сервера с новым объектом и объектом для проверки правильности кэша, однако, промежуточный кэш должен сравнить возвращенный объект для проверки правильности с тем, предоставленным в запросе клиента, используя сильную функцию сравнения. Если объект для проверки правильности клиента равен серверу происхождения, то промежуточный кэш просто возвращается 304 (Not Modified). Иначе, он возвращает новый объект с 200 (OK) ответ.
Если запрос включает директиву no-cache, он не должен включить min-fresh, max-stale, или max-age.
В некоторых случаях, например, времена чрезвычайно плохого сетевого обеспечения связи, клиент, возможно, хочет кэш, чтобы возвратить только те ответы, которые оно в настоящий момент хранило, а не перезагрузить или повторно проверить достоверность с сервером происхождения. Чтобы сделать это, клиент может включить директиву only-if-cached в запрос. Если он получает эту директиву, кэш ДОЛЖЕН или ответить, используя кэшируемый элемент, который совместим с другими ограничениями запроса, или отвечать 504 (Gateway Timeout) состояние. Однако, если группой кэшей управляют как объединенная система с хорошим внутренним обеспечением связи, такой запрос МОЖЕТ быть отправлен в пределах той группы кэшей.
Поскольку кэш может быть конфигурирован, чтобы проигнорировать указанное время expiration сервера, и потому что клиентский запрос может включить директиву max-stale (который имеет подобный эффект), протокол также включает механизм для сервера происхождения, чтобы потребовать придания вновь юридической силы элемента кэша на любом последующем использовании. Когда директива must-revalidate присутствует в ответе, полученном кэшем, тот кэш не ДОЛЖЕН использовать элемент после того, как он становится устарелым, чтобы ответить на последующий запрос без первой перепроверки достоверности его с сервером происхождения. (То есть, кэш должен сделать непрерывное придание вновь юридической силы каждый раз, если, базируемый исключительно на значении Expires ИЛИ max-age сервера происхождения, кэшируемый ответ является устарелым).
Директива must-revalidate необходима, чтобы поддержать надежную операцию для определенных возможностей протокола. При всех обстоятельствах HTTP/1.1 кэш ДОЛЖЕН повиноваться директиве must-revalidate; в частности если кэш не может достигнуть сервера происхождения по какой-нибудь причине, он ДОЛЖЕН генерировать 504 (Gateway Timeout) ответ.
Серверы должны отправить директиву must-revalidate, если и только если отказ повторно проверить достоверность запроса на объекте мог закончиться неправильной операцией, например, тихо невыполняемой финансовой транзакцией. Получатели не ДОЛЖНЫ предпринять автоматизированное действие, которое нарушает эту директиву, и не ДОЛЖНО автоматически предоставить неутвержденную копию объекта, если придание вновь юридической силы терпит неудачу.
Хотя этому не рекомендуют, пользовательские агенты, действующие при серьезных ограничениях обеспечения связи, могут нарушить эту директиву, но, если так, ДОЛЖНЫ явно предупредить пользователя, что неутвержденный ответ был предоставлен. Предупреждение ДОЛЖНО быть предоставлено на каждом неутвержденном доступе, и ДОЛЖНО потребовать явного пользовательского подтверждения.
У директивы proxy-revalidate есть то же самое значение как mustrevalidate директива, за исключением того, что он не применяется к non-shared кэши user agent. Он может использоваться на ответе на аутентифицированный запрос, чтобы разрешить кэшу пользователя хранить и более позднее возвращение ответ, не будучи должный повторно проверить достоверность его (так как он уже аутентифицировался однажды тем пользователем), все еще требуя прокси, которые обслуживают много пользователей, чтобы повторно проверить достоверность каждый раз когда (чтобы удостовериться, что каждый пользователь аутентифицировался). Обратите внимание, что такие аутентифицированные ответы также нуждаются в кэше public управлять директивой, чтобы позволить им кэшироваться вообще.