WikiDer > HTTP ETag

HTTP ETag

HTTP
Способы запроса
Поля заголовка
Коды состояния
Методы контроля доступа безопасности
Уязвимости безопасности

В ETag или же тег объекта часть HTTP, протокол для Всемирная паутина. Это один из нескольких механизмов, которые HTTP предоставляет Веб-кеш проверка, которая позволяет клиенту делать условные запросы. Это позволяет кэшировать более эффективно и экономит полосу пропускания, поскольку веб-серверу не нужно отправлять полный ответ, если содержимое не изменилось. ETags также можно использовать для оптимистичный контроль параллелизма,[1] как способ предотвратить перезапись друг друга при одновременном обновлении ресурса.

ETag - это непрозрачный идентификатор, назначаемый веб-сервером определенной версии ресурса, найденного в URL. Если представление ресурса по этому URL-адресу когда-либо изменяется, назначается новый и другой ETag. Используемые таким образом ETag похожи на отпечатки пальцев и его можно быстро сравнить, чтобы определить, одинаковы ли два представления ресурса.

Поколение ETag

Использование ETags в заголовке HTTP необязательно (не обязательно, как в некоторых других полях заголовка HTTP 1.1). Метод, с помощью которого генерируются ETag, никогда не указывался в спецификации HTTP.

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

Чтобы избежать использования устаревших данных кэша, методы, используемые для генерации ETag, должны гарантировать (насколько это возможно), что каждый ETag уникален. Тем не менее, функция генерации ETag может считаться «пригодной для использования», если может быть доказано (математически), что дублирование ETag будет «приемлемо редко», даже если оно может или произойдет.

RFC-7232 прямо заявляет, что ETags должны быть кодирование содержимого осведомлены, например

ETag: "123-a" - без кодирования содержимогоETag: "123-b" - для кодирования содержимого: gzip

Некоторые ранее контрольная сумма функции, которые были слабее, чем CRC32 или CRC64, как известно, страдают от проблем с конфликтом хэша. Таким образом, они не были хорошими кандидатами для использования в генерации ETag.

Сильная и слабая проверка

Механизм ETag поддерживает как сильная проверка и слабая проверка. Их отличает наличие начального "W /" в идентификаторе ETag, например:

«123456789» - сильный валидатор ETagW / «123456789» - слабый валидатор ETag

Строго проверяющее совпадение ETag указывает, что содержимое двух представлений ресурса побайтово идентично и что все другие поля объекта (например, Content-Language) также не изменились. Сильные ETags позволяют кэшировать и повторно собирать частичные ответы, как в случае с запросы байтового диапазона.

Слабо подтверждающее совпадение ETag указывает только на то, что эти два представления семантически эквивалентный, что означает, что для практических целей они взаимозаменяемы и можно использовать кэшированные копии. Однако представления ресурсов не обязательно побайтово идентичны, и поэтому слабые ETag не подходят для запросов с байтовым диапазоном. Слабые ETags могут быть полезны в случаях, когда сильные ETags нецелесообразны для генерации веб-сервера, например, с динамически генерируемый контент.

Типичное использование

Обычно при получении URL-адреса веб-сервер возвращает текущее представление ресурса вместе с соответствующим ему значением ETag, которое помещается в поле "ETag" заголовка HTTP-ответа:

ETag: "686897696a7c876b7e"

Затем клиент может решить кэшировать представление вместе со своим ETag. Позже, если клиент захочет снова получить тот же ресурс URL, он сначала определит, истек ли срок действия локально кэшированной версии URL (с помощью заголовков Cache-Control и Expire). Если срок действия URL-адреса не истек, он получит локально кэшированный ресурс. Если определено, что срок действия URL-адреса истек ( несвежий), клиент отправит запрос на сервер, который включает ранее сохраненную копию ETag в поле «If-None-Match».[2]

Если-None-Match: "686897696a7c876b7e"

По этому последующему запросу сервер теперь может сравнить ETag клиента с ETag для текущей версии ресурса. Если значения ETag совпадают, что означает, что ресурс не изменился, сервер может отправить очень короткий ответ с HTTP 304 без изменений положение дел. Статус 304 сообщает клиенту, что его кешированная версия все еще хороша и что он должен ее использовать.

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

Значения ETag можно использовать в Мониторинг веб-страниц системы. Эффективному мониторингу веб-страниц препятствует тот факт, что большинство веб-сайтов не устанавливают заголовки ETag для веб-страниц. Когда веб-монитор не показывает, был ли изменен веб-контент, весь контент должен быть извлечен и проанализирован с использованием вычислительных ресурсов как для издателя, так и для подписчика.

Несоответствующее обнаружение ETag

Веб-сайт с ошибками может иногда не обновлять ETag после обновления его семантического ресурса. По состоянию на 2019 год, примером такого известного сайта является export.arxiv.org.[3] В результате неправильно возвращенный ответ имеет статус 304, и клиент не может получить обновленный ресурс. Чтобы обнаружить такой сайт с ошибками:

  • Кэшируйте ответ и ETag, предполагая, что есть ETag и что ответ не был прерван.
  • Для последующего запроса, который включал бы заголовок If-None-Match, не отправляйте этот заголовок со случайной вероятностью 20%. С такой вероятностью, если ответ возвращает измененный контент, но тот же ETag, что и ранее кэшированный, отметьте веб-сайт как ошибочный и отключите для него кеширование ETag. Напоминаем, что для сильного ETag сравнение содержимого может быть побайтным, тогда как для слабого ETag проверяется только семантическая эквивалентность.

Отслеживание с помощью ETags

ETags можно использовать для отслеживания уникальных пользователей,[4] в качестве HTTP куки все чаще удаляются пользователями, заботящимися о конфиденциальности. В июле 2011 г. Ашкан Солтани и команда исследователей из Калифорнийский университет в Беркли сообщил, что ряд веб-сайтов, в том числе Hulu, использовали ETags для отслеживания.[5] Hulu и KISSmetrics прекратили «возрождение» с 29 июля 2011 г.[6] поскольку KISSmetrics и более 20 его клиентов сталкиваются с коллективный иск по поводу использования "не удаляемого" файлы cookie для отслеживания частично с использованием ETags.[7]

Поскольку ETag кэшируются браузером и возвращаются с последующими запросами для того же ресурса, сервер отслеживания может просто повторять любой ETag, полученный от браузера, чтобы гарантировать, что назначенный ETag сохраняется бесконечно (аналогично постоянные куки). Дополнительные заголовки кэширования также могут улучшить сохранность данных ETag.[8]

ETag можно удалить, очистив кеш браузера (реализации различаются).

Рекомендации

  1. ^ «Редактирование Интернета - обнаружение проблемы с утерянным обновлением с помощью незарезервированной проверки». Примечание W3C. 10 мая 1999 г.
  2. ^ Mozilla. «Этаг». Etag. Mozilla.
  3. ^ "Несоответствие export.arxiv.org ETag".
  4. ^ "отслеживание без файлов cookie". 17 февраля 2003 г.
  5. ^ «Файлы cookie Flash и конфиденциальность II: теперь с возрождением HTML5 и ETag». 29 июля 2011 г. SSRN 1898390. Цитировать журнал требует | журнал = (помощь)
  6. ^ "Respawn Redux". 11 августа 2011 г.
  7. ^ AOL, Spotify, GigaOm, Etsy, KISSmetrics подали в суд из-за не удаляемых файлов cookie для отслеживания
  8. ^ Файлы cookie без файлов cookie (с использованием ETags в качестве файлов cookie)

внешняя ссылка