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

13.3.4. Правила когда использовать объектные отметки (Entity Tags) и даты последнего изменения (Last-modified Dates)

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

HTTP/1.1 серверы происхождения:

  • ДОЛЖЕН отправить объект для проверки правильности тэга объекта, если не выполнимо генерировать тот.
  • МОЖЕТ отправить слабый тэг объекта вместо сильного тэга объекта, если рассмотрения производительности поддерживают использование слабых тэгов объекта, или если он невыполним, чтобы отправить сильный тэг объекта.
  • ДОЛЖЕН отправить значение Last-Modified, если выполнимо отправить один, если риск расстройства в семантической прозрачности, которая могла закончиться от использования этой даты заголовком If-Modified-Since, не приведет к серьезным проблемам.

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

Чтобы быть юридическим, сильный тэг объекта ДОЛЖЕН измениться всякий раз, когда связанное значение объекта изменяется в любом случае. Слабый тэг объекта ДОЛЖЕН измениться всякий раз, когда связанный объект изменяется семантически существенным способом.

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

HTTP/1.1 клиенты:

  • Если тэг объекта был предоставлен сервером происхождения, ДОЛЖЕН использовать тот тэг объекта в любом запросе cache-conditional (используя If-Match или If-None-Match).
  • Если только значение Last-Modified было предоставлено сервером происхождения, ДОЛЖЕН использовать то значение в неподдиапазоне запросы cache-conditional (используя If-Modified-Since).
  • Если только значение Last-Modified было предоставлено HTTP/1.0 сервер происхождения, МОЖЕТ использовать то значение в поддиапазоне запросы cache-conditional (используя If-Unmodified-Since:). user agent должен предоставить способ отключить это, в случае трудности.
  • Если и тэг объекта и значение Last-Modified были предоставлены сервером происхождения, ДОЛЖЕН использовать оба объекта для проверки правильности в запросах cache-conditional. Это позволяет и HTTP/1.0 и HTTP/1.1 кэши отвечать соответственно.
2007 - 2017 © Русские переводы RFC, IETF, ISOC.