HTTP ETag

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

ETag или entity tag — часть HTTP, протокола World Wide Web. Это один из нескольких механизмов, с помощью которых HTTP обеспечивает веб проверку кэша, и который позволяет клиенту делать условный запрос. Это позволяет кэшу быть более эффективным и экономит пропускную способность, так как веб-серверу не нужно отправлять полный ответ, если содержимое не изменилось. ETags также может быть использован для оптимального управления многопоточностью[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 заголовки веб-страниц. Когда веб-монитор не имеет никаких подсказок был ли веб-контент изменен, весь контент должен быть восстановлен, и проанализирован, используя вычислительные ресурсы как опубликовавшего контент, так и того, кто хочет его просмотреть.

Отслеживание с помощью Etag[править | править вики-текст]

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

Ссылки[править | править вики-текст]

Внешние ссылки[править | править вики-текст]