MDN’s new design is in Beta! A sneak peek:

현재 번역은 완벽하지 않습니다. 한국어로 문서 번역에 동참해주세요.

ETag HTTP 응답 헤더는 특정 버전의 리소스를 식별하는 식별자입니다. 웹 서버가 내용을 확인하고 변하지 않았으면, 웹 서버로 full 요청을 보내지 않기 때문에, 캐쉬가 더 효율적이게 되고, 대역폭도 아낄 수 있습니다. 허나, 만약 내용이 변경되었다면, "mid-air collions" 이라는 리소스 간의 동시 다발적 수정 및 덮어쓰기 현상을 막는데 유용하게 사용됩니다.

만약 특정 URL 의 리소스가 변경된다면, 새로운 ETag 가 생성됩니다. ETag 는 지문과 같은 역할을 하면서 다른 서버들이 추적하는 용도에 이용되기도 합니다. ETag 를 비교하여 리소스가 서로 같은지의 여부를 빠르게 판단할 수 있지만, 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/ Optional
'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"

Avoiding mid-air collisions

With the help of the ETag and the If-Match headers, you are able to detect mid-air edit collisions.

For example when editing MDN, the current wiki content is hashed and put into an Etag in the response:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4

When saving changes to a wiki page (posting data), the POST request will contain the If-Match header containing the ETag values to check freshness against.

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

If the hashes don't match, it means that the document has been edited in-between and a 412 Precondition Failed error is thrown.

Caching of unchanged resources

Another typical use case of the ETag header is to cache resources that are unchanged. If a user visits a given URL again (that has an ETag set), and it is stale, that is too old to be considered usable, the client will send the value of its ETag along in an If-None-Match header field:

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

The server compares the client's ETag (sent with If-None-Match) with the ETag for its current version of the resource and if both values match (that is, the resource has not changed), the server send back a 304 Not Modified status, without any body, which tells the client that the cached version of the response is still good to use (fresh).


Specification Title
RFC 7232, section 2.3: ETag Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests

Browser compatibility

Feature Chrome Edge Firefox Internet Explorer Opera Safari Servo
Feature Android Chrome for Android Edge Mobile Firefox for Android IE Mobile Opera Mobile Safari Mobile

See also

문서 태그 및 공헌자

 이 페이지의 공헌자: joshua1988
 최종 변경: joshua1988,