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

13.6. Кэширование переговорных ответов (Negotiated Responses)

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

Сервер ДОЛЖЕН использовать поле заголовка Vary (раздел 14.43), чтобы сообщить кэшу того, что размерности поля заголовка используются, чтобы выбрать среди множественных представлений cachable ответа. Кэш может использовать выбранное представление (объект, включенный в тот определенный ответ) для того, чтобы ответить на последующие запросы на том ресурсе только, когда у последующих запросов есть те же самые или эквивалентные значения для всех полей заголовка, указанных в заголовке ответа Vary. Запросы с другим значением для один или больше тех полей заголовка были бы отправлены к серверу происхождения.

Если бы тэг объекта был назначен представлению, то отправленный запрос ДОЛЖЕН быть условным выражением и включить тэгы объекта в поле заголовка IfNone-соответствия от всех его входов кэша для RequestURI. Это передает серверу набор объектов, в настоящий момент хранивших кэшем, так, чтобы, если любой из этих объектов соответствует запрошенному объекту, сервер мог использовать заголовок ETag в его 304 (Not Modified) ответ, чтобы сказать кэш, какой элемент является соответствующим. Если entity-tag новых соответствий ответа тот из существующего элемента, новый ответ ДОЛЖЕН использоваться, чтобы обновить поля заголовка существующего элемента, и результат ДОЛЖЕН быть возвращен клиенту.

Поле заголовка Vary может также сообщить кэшу, что представление было выбрано, используя критерии, не ограниченные заголовками запроса; в этом случае, кэш не ДОЛЖЕН использовать ответ в ответе на последующий запрос, если кэш не передает новый запрос на сервер происхождения в условном запросе, и сервер отвечает 304 (Not Modified), включая тэг объекта или Content-Location, который указывает, какой объект должен использоваться.

Если любой из существующих входов кэша содержит только частичный контент для связанного объекта, его entity-tag не ДОЛЖЕН быть включен в заголовок If-None-Match, если запрос не для диапазона, которому полностью удовлетворил бы тот элемент.

Если кэш получает успешный ответ, соответствия поля Content-Location которого тот из существующего элемента кэша для того же самого RequestURI, entity-tag которого отличается от того из существующего элемента, и чей Date более свеж чем тот из существующего элемента, существующий элемент не ДОЛЖЕН быть возвращен в ответ на будущие запросы, и должен быть удален из кэша.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.