HTTP ETag

Эта статья находится на начальном уровне проработки, в одной из её версий выборочно используется текст из источника, распространяемого под свободной лицензией
Материал из энциклопедии Руниверсалис

ETag или entity tag — один из регламентируемых спецификацией RFC 7232, служебных заголовков протокола HTTP/1.1, который может быть установлен веб-сервером в фазе формирования ответа, на полученный от клиента запрос. Содержимое заголовка ETag является идентификатором, значение которого прямо зависит от состояния загружаемого клиентом ресурса. В дальнейшем, этот идентификатор, используется с целью актуализации состояния загруженного ресурса его оригиналу, расположенному на Веб-сервере. Что достигается путём отправки серверу HTTP/1.1 запроса с указанием ETag идентификатора как значении заголовка - If-None-Match. Сервер, обнаружив такой заголовок, на основании сравнения его значения с текущим состоянием ресурса сообщает клиенту о том, что копия, хранящаяся в кэше клиента, актуальна т.е. необходимости в повторной загрузке нет, или, в противном случае, необходима загрузка актуальной версии.

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

Риски использования

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

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

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

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

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

Механизм ETag поддерживает как сильные, так и слабые проверки. Они отличаются наличием начального W/ в идентификаторе ETag, например, "123456789" (сильная проверка ETag), W/"123456789" (слабая проверка ETag).

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

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

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

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

ETag: "686897696a7c876b7e"

Клиент может затем кэшировать ресурс вместе с его ETag. Позже, если клиент хочет получить страницу с того же адреса, он пошлет её ранее сохранённую копию ETag вместе с запросом в поле If-None-Match.

If-None-Match: "686897696a7c876b7e"

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

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

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

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

ETags может быть использована для отслеживания уникальных пользователей[1], так как HTTP cookie могут быть удалены стремящимися к полной конфиденциальности пользователями. В июле 2011 года Ashkan Солтани и команда исследователей из Калифорнийского университета в Беркли сообщили, что ряд веб-сайтов, в том числе Hulu.com, использовали ETag для отслеживания таких целей[2]. Hulu и KISSmetrics перестали это делать по состоянию на 29 июля 2011[3],так как KISSmetrics и более 20 её клиентов столкнулись с групповым иском по поводу использования «неудаляемых» следящих cookie частично связанных с использованием ETag[4].

Примечания

  1. ↑ tracking without cookies (недоступная ссылка) (17 февраля 2003). Архивировано 3 июня 2013 года.
  2. ↑ Flash Cookies and Privacy II: Now with HTML5 and ETag Respawning (недоступная ссылка) (29 июля 2011). Архивировано 3 июня 2013 года.
  3. ↑ Respawn Redux (недоступная ссылка) (11 августа 2011). Архивировано 3 июня 2013 года.
  4. ↑ AOL, Spotify, GigaOm, Etsy, KISSmetrics sued over undeletable tracking cookies. Дата обращения: 2 июня 2013. Архивировано 22 мая 2014 года.

Ссылки

Источник — https://xn--h1ajim.xn--p1ai/index.php?title=HTTP_ETag&oldid=10381988