13.3.3. Слабое и сильное сравнение
И начиная с серверы происхождения и начиная с кэши сравнят два объекта для проверки правильности, чтобы решить, представляют ли они те же самые или другие объекты, обычно можно было бы ожидать это, если объект (тело объекта или любой объект — заголовки) изменения в любом случае, то связанный объект для проверки правильности изменится также. Если это истинно, то мы называем этот объект для проверки правильности "сильным объектом для проверки правильности."
Однако, могут быть случаи, когда сервер предпочитает изменять объект для проверки правильности только на семантически существенных изменениях, и не, когда незначащие аспекты объекта изменяются. Объект для проверки правильности, который не всегда изменяется, когда ресурс изменяется, является "слабым объектом для проверки правильности."
Тэгы объекта обычно — "сильные объекты для проверки правильности," но протокол предоставляет механизм, чтобы отметить тэг объекта как "слабый". Можно думать о сильном объекте для проверки правильности как о том, который изменяется всякий раз, когда биты объекта изменяются, в то время как слабое значение изменяется всякий раз, когда значение объекта изменяется. Альтернативно, можно думать о сильном объекте для проверки правильности как о части идентификатора для специфичного объекта, в то время как слабый объект для проверки правильности — часть идентификатора для ряда семантически эквивалентных объектов.
Обратите внимание: Один пример сильного объекта для проверки правильности — целое число, которое увеличено в устойчивой памяти каждый раз, когда объект изменен.
Время модификации объекта, если представлено с одно-секундной разрешающей способностью, могло бы быть слабым объектом для проверки правильности, так как он возможен, что ресурс может быть изменен дважды в течение отдельной секунды.
Поддержка слабых объектов для проверки правильности является опциональной; однако, слабые объекты для проверки правильности учитывают более эффективное кэширование эквивалентных объектов; например, счетчик посещений на сайте вероятно достаточно хорош, если он обновлен каждые несколько дней или недель, и любое значение в течение той точки вероятно "достаточно хорошее", чтобы быть эквивалентным.
"Использование" объекта для проверки правильности или когда клиент генерирует запрос и включает объект для проверки правильности в поле заголовка проверки достоверности, или когда сервер сравнивает два объекта для проверки правильности.
Сильные объекты для проверки правильности пригодны для использования в любом контексте. Слабые объекты для проверки правильности только пригодны для использования в контекстах, которые не зависят от точного равенства объекта. Например, любой вид пригоден для использования для условного GET полного объекта. Однако, только сильный объект для проверки правильности пригоден для использования для поиска поддиапазона, так как иначе клиент может закончить с внутренне непоследовательным объектом.
Единственная функция, которую протокол HTTP/1.1 определяет в объектах для проверки правильности, является сравнением. Есть две функции сравнения объекта для проверки правильности, в зависимости от того, позволяет ли контекст сравнения использование слабых объектов для проверки правильности или нет:
- Сильная функция сравнения: чтобы рассматриваться равный, оба объекта для проверки правильности должны быть идентичными каждым способом, и ни один не может быть слабым.
- Слабая функция сравнения: чтобы рассматриваться равный, оба объекта для проверки правильности должны быть идентичными каждым способом, но или или они оба могут быть отмечены как "слабые", не затрагивая результат.
Слабая функция MAY сравнения использоваться для простого (неподдиапазон) запросы GET. Сильная функция MUST сравнения использоваться во всех других случаях.
Тэг объекта силен, если он явно не отмечен как слабый. Раздел 3.11 дает синтаксис для тэгов объекта.
Время Last-Modified, когда используется как объект для проверки правильности в запросе, неявно слабо, если он не возможен вывести, что он силен, используя следующие правила:
- Объект для проверки правильности сравнивается сервером происхождения с фактическим текущим объектом для проверки правильности для объекта и,
- Тот сервер происхождения надежно знает, что связанный объект не изменялся дважды во время второго, охваченного представленным объектом для проверки правильности.
или
- Объект для проверки правильности собирается использоваться клиентом в "если изменено" С тех пор или заголовок If-Unmodified-Since, потому что у клиента есть элемент кэша для связанного объекта, и
- Тот элемент кэша включает значение Date, которое дает время, когда сервер происхождения отправлял оригинальный ответ, и
- Представленное время Last-Modified по крайней мере за 60 секунд до значения Date.
или
- Объект для проверки правильности сравнивается промежуточным кэшем с объектом для проверки правильности, сохраненным в его элементе кэша для объекта, и
- Тот элемент кэша включает значение Date, которое дает время, когда сервер происхождения отправлял оригинальный ответ, и
- Представленное время Last-Modified по крайней мере за 60 секунд до значения Date.
Этот метод полагается на факт, что, если два других ответа отправил сервер происхождения в течение той же самой секунды, но у обоих было то же самое время Last-Modified, то у по крайней мере одного из тех ответов будет значение Date равным его времени Last-Modified. Произвольные 60-вторых пределов принимают меры против возможности, что Date и Последний — значения Modified сгенерирован от других часов, или в несколько другие времена во время подготовки ответа. Реализация может использовать значение, большее чем 60 секунд, если полагается, что 60 секунд слишком коротки.
Если клиент желает выполнить поиск поддиапазона на значении, для которого у него есть только время Last-Modified и никакой непрозрачный объект для проверки правильности, он может сделать это, только если время Last-Modified сильно в смысле, описанном здесь.
Кэш или сервер происхождения, получающий запрос cache-conditional, кроме полного тела запрос GET, ДОЛЖНЫ использовать сильную функцию сравнения, чтобы оценить условие.
Эти правила позволяют HTTP/1.1 кэши и клиенты безопасно исполнять под — поиски диапазона на значениях, которые были получены из HTTP/1.0 серверы.