ETag или entity tag — часть HTTP, протокола World Wide Web. Это один из нескольких механизмов, с помощью которых HTTP обеспечивает веб-проверку кэша и который позволяет клиенту делать условный запрос. Это позволяет кэшу быть более эффективным и экономит пропускную способность, так как веб-серверу не нужно отправлять полный ответ, если содержимое не изменилось. ETag также может быть использован для оптимального управления многопоточностью[1] как способ, чтобы помочь предотвратить одновременное обновление и перезапись ресурса.
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 заголовки веб-страниц. Когда веб-монитор не имеет никаких подсказок, был ли веб-контент изменён, весь контент должен быть восстановлен и проанализирован, используя вычислительные ресурсы как опубликовавшего контент, так и того, кто хочет его просмотреть.
ETags может быть использована для отслеживания уникальных пользователей[2], так как HTTP cookie могут быть удалены стремящимися к полной конфиденциальности пользователями. В июле 2011 года Ashkan Солтани и команда исследователей из Калифорнийского университета в Беркли сообщили, что ряд веб-сайтов, в том числе Hulu.com, использовали ETag для отслеживания таких целей[3]. Hulu и KISSmetrics перестали это делать по состоянию на 29 июля 2011[4],так как KISSmetrics и более 20 её клиентов столкнулись с групповым иском по поводу использования «неудаляемых» следящих cookie частично связанных с использованием ETag[5].
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .