if-Modified-Since против 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.
• Если вы обслуживаете динамическую веб-страницу, созданную из нескольких 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 содержат информацию о системе inode , поэтому перемещение файла на другой диск также может изменить ETag.

Answer 3

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

Answer 4

Как указано в рекомендациях Google:

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

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

Answer 5

If-Modified-Since использует дату, а If-None-Match использует ETag . Они оба могут использоваться для «страниц» (то есть HTML) и других файлов.

Answer 6

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

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

Answer 7

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

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