We're looking for a user researcher to understand the needs of developers and designers. Is this you or someone you know? Check out the post: https://mzl.la/2IGzdXS

Перевод не завершен. Пожалуйста, помогите перевести эту статью с английского.


The ETag HTTP response header is an identifier for a specific version of a resource. It allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. On the other side, if the content has changed, etags are useful to help prevent simultaneous updates of a resource from overwriting each other ("mid-air collisions").

If the resource at a given URL changes, a new Etag value must be generated. Etags are therefore similar to fingerprints and might also be used for tracking purposes by some servers. A comparison of them allows to quickly determine whether two representations of a resource are the same, but they might also be set to persist indefinitely by a tracking server.

Header type Response header
Forbidden header name no


ETag: W/"<etag_value>"
ETag: "<etag_value>"


W/ Необязательный
'W/' (case-sensitive) indicates that a weak validator is used. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult to generate efficiently. Weak Etag values of two representations of the same resources might be semantically equivalent, but not byte-for-byte identical.
Entity tags uniquely representing the requested resources. They are a string of ASCII characters placed between double quotes (Like "675af34563dc-tr34"). The method by which ETag values are generated is not specified. Oftentimes, a hash of the content, a hash of the last modification timestamp, or just a revision number is used. For example, MDN uses a hash of hexadecimal digits of the wiki content.


ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

Как избежать коллизий в процессе работы приложения

С помощью заголовков ETag и If-Match, существует возможность обнаружить коллизии в процессе работы приложения.

Например, при редактировании MDN, текущее содержимое статьи захэшировано и помещено в ответ при помощи заголовока Etag:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

При сохранении изменений в статье (данные отправляются), POST запрос будет содержать заголовок If-Match, значение которого эквивалетно значению ETag. Это позволяет проверить актуальность данных.

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Если хэши из заголовков не совпадают, это означает что данные уже были изменены между запросами (in-between) и будет возвращена ошибка 412 Precondition Failed.

Кэширование неизменямых ресурсов

Другая типичная ситуация для использования ETag — кэширование ресурсов, которые не будут изменяться. Если пользовать повторно посещает URL-адрес (с утановленным заголовком ETag), и при этом данные слишком устарели и не могут быть использованы. Тогда клиент отправит значение ETag внутри заголовка If-None-Match:

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

После чего сервер сравнит клиентский ETag (отправленный с помощью If-None-Match) с ETag для текущей версии ресурса и если их значения совпадают (т.е. ресурсы не были изменены), сервер вернет статус 304 Not Modified, без тела ответа. Такой ответ сообщает клиенту что закэшированная версия ресурса актуальна и готова к использованию.


Specification Title
RFC 7232, секция 2.3: ETag Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests

Browser compatibility

ВозможностьChromeEdgeFirefoxInternet ExplorerOperaSafari
Базовая поддержка Да Да Да Да Да Да
ВозможностьAndroid webviewChrome for AndroidEdge mobileFirefox for AndroidOpera AndroidiOS SafariSamsung Internet
Базовая поддержка Да Да Да Да Да Да Да

See also

Метки документа и участники

Внесли вклад в эту страницу: Creepypoke
Обновлялась последний раз: Creepypoke,