HTTP ETag

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

ETag — это закрытый идентификатор, присвоенный веб-сервером определённой версии ресурса, находящегося по указанному URL. Если содержание ресурса для этого адреса меняется на новое, назначается и новый ETag. Использование в таком ключе ETags аналогично использованию отпечатков пальцев: можно быстро сравнить и определить, являются ли две версии ресурса одинаковыми или нет. Сравнение 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 может быть использована для отслеживания уникальных пользователей, так как HTTP cookie могут быть удалены стремящимися к полной конфиденциальности пользователями. В июле 2011 года Ashkan Солтани и команда исследователей из Калифорнийского университета в Беркли сообщили, что ряд веб-сайтов, в том числе Hulu.com, использовали ETag для отслеживания таких целей. Hulu и KISSmetrics перестали это делать по состоянию на 29 июля 2011,так как KISSmetrics и более 20 её клиентов столкнулись с групповым иском по поводу использования «неудаляемых» следящих cookie частично связанных с использованием ETag.

Ссылки

• ETag in HTTP/1.1 specification
• Concerning Etags and Datestamps by Lars R. Clausen (2004)
• Apache HTTP Server Documentation — FileETag Directive
• Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout, W3C Note, 10 May 1999.
• Old SQUID Development projects — ETag support Архивная копия от 23 сентября 2012 на Wayback Machine (completed in 2001)
• Using ETags to Reduce Bandwidth & Workload with Spring & Hibernate