if-Modified-Since против if-none-match
В чем может быть разница между if-Modified-Since и If-none-match? У меня такое ощущение, что if-none-match используется для файлов, тогда как if-Modified-Since используется для страниц?
7 ответов
Что касается различий между Last-Modified/If-Modified-Since а также ETag/If-None-Match:
Оба могут быть использованы взаимозаменяемо. Однако, в зависимости от типа ресурса и того, как он генерируется на сервере, один или другой вопрос ("был ли он изменен, так как...?" / "Соответствует ли этот ETag?") Может быть проще ответить,
Примеры:
- Если вы обслуживаете файлы, используйте файл
mtimeкакLast-Modifiedдата является самым простым решением. - Если вы работаете с динамической веб-страницей, созданной из нескольких SQL-запросов, проверка того, изменились ли данные, возвращаемые любым из этих запросов, может оказаться нецелесообразной (если только у всех из них не имеется своего рода "последний измененный" столбец). В этом случае, используя, например, хэш md5 содержимого страницы в качестве
ETagбудет намного проще
OTOH, это означает, что вам все равно нужно сгенерировать всю страницу на сервере, даже для условного GET. Выяснение того, что именно должно входить в ETag (первичные ключи, номера ревизий и т. Д.), Поможет вам сэкономить здесь много времени.
Смотрите эти ссылки для более подробной информации по теме:
If-Modified-Since по сравнению с Last-Modified в то время как If-None-Match по сравнению с ETag, И то и другое Modified-Since а также ETag может использоваться для идентификации конкретного варианта ресурса.
Но сравнение If-Modified-Since в Last-Modified дает вам информацию, является ли кэшированный вариант старше или новее, тогда как сравнение If-None-Match в ETag просто дает вам информацию, являются ли оба идентичных или нет. Кроме того, большинство из ETag генераторы содержат информацию о конкретном системном иноде, поэтому перемещение файла на другой диск может изменить ETag также.
Значение метки времени, используемое в Last-Modified/If-Modified-Since, имеет ограниченную точность - одну секунду, и этого просто недостаточно для быстрой смены контента, такого как, например, приложение для веб-чата, где в любую секунду может быть отправлено более одного сообщения., ETag/If-None-Match может помочь решить эту проблему.
Как указано в лучших практиках Google:
Для всех кэшируемых ресурсов важно указать одно из значений Max-age Expires или Cache-Control и одно из Last-Modified или ETag. Излишне указывать как Expires, так и Cache-Control: max-age или указывать как Last-Modified и ETag.
https://developers.google.com/speed/docs/best-practices/caching
If-Modified-Since использует дату, в то время как If-None-Match использует ETag. Они оба могут быть использованы для "страниц" (т.е. HTML) и других файлов.
Если сервер не объявил сервер слабым, ETag считается сильным валидатором и, таким образом, может использоваться для удовлетворения условного ранжированного запроса. Тем не менее, большинство автоматически генерируемых ETag обнаруживают трудности в ситуациях фермы серверов, поскольку они часто используют информацию inode и / или уникальный постоянный счетчик. На практике я обнаружил, что заголовок Last Modified достаточен для довольно статического контента, например, для обслуживания защищенного статического контента, поскольку время записи файла делает достаточно хороший валидатор.
ETag, безусловно, самый гибкий. Соответствующие клиенты должны отправлять ETag в условном запросе, тогда как они ДОЛЖНЫ отправлять оба, если они доступны.
Заголовок If-Modified-Since используется для указания времени, когда браузер последний раз получил запрошенный ресурс. Заголовок If-None-Match используется для указания тега объекта, который сервер выпустил с запрошенным ресурсом, когда он был получен в последний раз.
Двумя описанными способами эти заголовки используются для поддержки кэширования содержимого в браузере, и они позволяют серверу инструктировать браузер использовать кэшированную копию ресурса, а не отвечать полным содержимым ресурса, если это не обязательно.