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

HTTP/1.1 кэш, после получения запроса, ДОЛЖЕН использовать самый ограничительный объект для проверки правильности, решая, соответствует ли элемент кэша клиента собственному элементу кэша кэша. Это — только выпуск, когда запрос содержит и тэг объекта и объект для проверки правильности даты последнего изменения (If-Modified-Since или If-Unmodified-Since).

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

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

13.3.5. Непроверяемые условия

Принцип позади тэгов объекта — то, что только сервисный автор знает, что семантика ресурса достаточно хорошо выбирает соответствующий механизм проверки правильности кэша, и спецификацию любой более сложной функции сравнения объекта для проверки правильности, чем равенство байта открыло бы кучу проблем. Таким образом, сравнения любых других заголовков (кроме Last-Modified, для совместимости с HTTP/1.0) никогда не используются в целях проверить достоверность элемента кэша.

Страница 81 из 160

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