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

Если ресурс по заданному URL изменился, будет сгенерированно новое значениеEtag. ПоэтомуEtag чем-то похож на отпечаток ("fingerprints") и может также быть использован для отслеживания предназначения некоторых серверов. Сравнение этих заголовков позволяет быстро определить являются ли два представления ресурса одними и теме же. Отслеживаемый сервер также может задать сохранять их постоянно.

Синтаксис

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

Директивы

W/Необязательный

'W/' (чувствителен к регистру) указывает, что используетсяслабый валидатор. Слабые валидаторы легко сгенерировать, но они намного реже используются для сравнения. Сильные валидаторы идеальны для сравнения, но их может быть очень сложно сгенерировать эффективно. Слабое значениеEtag двух представлений одного и того же ресурса может быть семантически одинаково, но не байт-в-байт.

"<etag_value>"

Тэг сущности, уникально представляющий запрашиваемый ресурс. Это строка ASCII кодов, заключённая в двойные кавычки (например,"675af34563dc-tr34"). Метод, по которому генерируются значенияETag, не определён. Обычно, используется хэш контента, хэш последнего времени модификации или просто номер ревизии. Например, MDN использует шестнадцатеричных хэш wiki-содержимого.

Примеры

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

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

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

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

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

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

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

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

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

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

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

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

Спецификации

Совместимость с браузерами

Смотрите также

• If-Match
• If-None-Match
• 304Not Modified
• 412Precondition Failed
• W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout