if-modified-since vs if-none-match

Question

В чем может быть разница между if-modified-since и if-none-match?У меня такое ощущение, что if-none-match используется для файлов, а if-modified-since — для страниц?

Answer 1

Что касается различий между Last-Modified/If-Modified-Since и ETag/If-None-Match:

Оба могут использоваться взаимозаменяемо.Однако в зависимости от типа ресурса и того, как он генерируется на сервере, на тот или иной вопрос («было ли это изменено с...?» / «это все еще соответствует этому ETag?») может быть проще ответить. .

Примеры:

• Если вы обслуживаете файлы, используя файл mtime как Last-Modified date - самое простое решение.
• Если вы обслуживаете динамическую веб-страницу, созданную на основе нескольких запросов SQL, проверка того, изменились ли данные, возвращаемые каким-либо из этих запросов, может быть непрактичной (если только все они не имеют своего рода столбец «последнее изменение»).В этом случае, используя, например.хеш md5 содержимого страницы в качестве ETag будет намного проще.
  OTOH, это означает, что вам все равно придется генерировать всю страницу на сервере даже для условного GET.Выяснение того, что именно должно войти в ETag (первичные ключи, номера ревизий,...и т. д.) может сэкономить вам много времени.

Более подробную информацию по этой теме можно найти по этим ссылкам:

• http://www.tbray.org/ongoing/When/200x/2008/08/14/Rails-ETags
• http://bitworking.org/news/150/REST-Tip-Deep-etags-give-you-more-benefits

Answer 2

If-Modified-Since сравнивается с Last-Modified тогда как If-None-Match сравнивается с ETag.Оба Modified-Since и ETag может использоваться для идентификации конкретного варианта ресурса.

Но сравнение If-Modified-Since к Last-Modified дает вам информацию, является ли кэшированный вариант старшая или новее тогда как сравнение If-None-Match к ETag просто дает вам информацию, являются ли оба идентичный или нет.Кроме того, большая часть ETag генераторы включают информацию о конкретной системе индексный дескриптор поэтому перемещение файла на другой диск может изменить ETag также.

Answer 3

Значение временной метки, используемое в Last-Modified/If-Modified-Since, имеет ограниченную точность - одну секунду, и этого просто недостаточно для быстрого изменения контента, например, приложения веб-чата, где в любую секунду может быть опубликовано более одного сообщения. .ETag/If-None-Match может помочь решить эту проблему.

Answer 4

Как указано в лучших практиках Google:

Важно указать один из значений Expires или Cache-Control max-age и один из Last-Modified или ETag для всех кэшируемых ресурсов.Излишним указывать как Expires, так и Cache-Control:max-age или указать Last-Modified и ETag.

https://developers.google.com/speed/docs/best-practices/caching

Answer 5

Если-Изменено-С тех пор использует дату, в то время как Если-Нет-Матча использует ETag.Оба они могут использоваться для «страниц» (т.е.HTML) и другие файлы.

Answer 6

Если сервер не указал его как слабый, ETag считается сильным валидатором и, таким образом, может использоваться для удовлетворения запроса с условным диапазоном.Однако большинство автоматически генерируемых ETag испытывают трудности в ситуациях с фермами серверов, поскольку они часто используют информацию об индексном дескрипторе и/или уникальный постоянный счетчик.На практике я обнаружил, что заголовка Last Modified достаточно для довольно статического контента, например.обслуживание защищенного статического контента, поскольку время записи файла делает его достаточно хорошим валидатором.

ETag на сегодняшний день является наиболее гибким.Соответствующие клиенты должны отправлять ETag в условном запросе, тогда как им СЛЕДУЕТ отправлять оба, если они доступны.

Answer 7

Заголовок If-Modified-Since используется для указания времени, когда браузер в последний раз получил запрошенный ресурс.Заголовок If-None-Match используется для указания тега объекта, который сервер выдал с запрошенным ресурсом при его последнем получении.

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