HTTP Etag

HTTP ETag
HTTP
HTTP logo.svg
요구 방식
헤더 필드
응답 상태 코드
보안 접근 제어 방법
보안 취약성

ETag 또는 엔티티 태그는 월드 와이드 웹 프로토콜인 HTTP의 일부입니다.HTTP가 웹 캐시 검증을 위해 제공하는 여러 메커니즘 중 하나이며, 이를 통해 클라이언트는 조건부 요청을 수행할 수 있습니다.내용이 변경되지 않은 경우 웹 서버가 완전한 응답을 보낼 필요가 없으므로 이 메커니즘을 통해 캐시의 효율성을 높이고 대역폭을 절약할 수 있습니다.ETAG는 자원의 동시 갱신이 서로 덮어쓰지 않도록 하기 위해 최적의 동시성[1] 제어에도 사용할 수 있습니다.

ETag는 [2]웹 서버가 URL에 있는 리소스의 특정 버전에 할당하는 불투명한 식별자입니다. 해당 URL의 리소스 표현이 변경되면 다른 새로운 ETag가 할당됩니다.이와 같이 ETAG를 사용하면 지문과 유사하며 리소스를 나타내는 두 가지 표현이 동일한지 여부를 빠르게 비교할 수 있습니다.

ETAG 생성

HTTP 헤더의 ETAG 사용은 옵션입니다(HTTP 1.1 헤더의 다른 일부 필드와 마찬가지로 필수는 아닙니다).ETAG를 생성하는 방법은 HTTP 사양에 지정되어 있지 않습니다.

ETag 생성의 일반적인 방법에는 리소스 콘텐츠의 충돌 방지 해시 함수, 마지막 수정 타임스탬프의 해시 또는 리비전 번호의 사용이 포함됩니다.

오래된 캐시 데이터의 사용을 피하기 위해 ETAG를 생성하는 방법은 (실용 가능한 한) 각 ETAG가 고유함을 보증해야 합니다.그러나 ETag 생성 함수는 ETag의 복제가 발생할 수 있거나 발생할 수 있더라도 "허용될 정도로 드문" 것으로 입증될 수 있다면 "사용 가능한" 것으로 판단할 수 있다.

RFC-7232에서는 ETAG는 콘텐츠코딩을 인식해야 한다고 명시되어 있습니다.

ETAG: "123-a" – Content-Encoding ETAG: "123-b" – Content-Encoding: gzip

CRC32 또는 CRC64보다 약한 이전의 체크섬 함수 중에는 해시 충돌 문제가 있는 것으로 알려져 있습니다.따라서 ETAG 세대에는 적합하지 않습니다.

강력한 검증과 약한 검증

ETag 메커니즘은 강력한 검증과 약한 검증을 모두 지원합니다.ETAG 식별자에 초기 "W/"가 있으면 다음과 같이 구별됩니다.

"123456789" – 강력한 ETAG 검증기 W/"123456789" – 약한 ETAG 검증기

ETag 일치가 강하게 검증되면 2개의 자원 표현 내용이 바이트 단위로 동일하며 다른 모든 엔티티 필드(Content-Language 등)도 변경되지 않았음을 나타냅니다.강력한 ETAG를 사용하면 바이트 범위 요구와 마찬가지로 부분 응답의 캐시 및 재구성이 가능합니다.

ETag 매치가 약하게 검증되면 두 표현은 의미론적으로 동일함을 나타낼 뿐입니다. 즉, 실제 목적상 서로 교환할 수 있으며 캐시된 복사본을 사용할 수 있습니다.단, 자원 표현은 바이트 대 바이트가 반드시 동일하다고는 할 수 없기 때문에 약한 ETAG는 바이트 범위 요구에 적합하지 않습니다.취약 ETAG는 웹 서버가 동적으로 생성된 콘텐츠 등 강력한 ETAG를 생성하기 어려운 경우에 유용합니다.

일반적인 사용법

통상, URL 를 취득하면, Web 서버는 자원의 현재 표현을 대응하는 ETAG 값과 함께 반환합니다.이 값은 HTTP 응답 헤더 「ETAG」필드에 배치됩니다.

ETAG: "68689796a7c876b7e"

그런 다음 클라이언트는 표현과 ETAG를 캐시하기로 결정할 수 있습니다.나중에 클라이언트가 같은 URL 리소스를 다시 취득할 경우 먼저 (Cache-Control 및 Expire 헤더를 통해) 로컬 캐시된 URL 버전이 만료되었는지 여부를 판단합니다.URL이 만료되지 않은 경우 로컬로 캐시된 리소스를 가져옵니다.URL이 만료되었다고 판단되면(오래된 경우), 클라이언트는 이전에 저장한ETag 복사본을 [If-None-Match]필드에 [3]포함하는 요구를 서버에 송신합니다. 

If-None-Match: "686897696a7c876b7e"

이 이후의 요구에 따라 서버는 클라이언트의 ETag를 자원의 현재 버전에 대한 ETag와 비교할 수 있습니다.ETAG 값이 일치하는 경우, 즉 리소스가 변경되지 않은 경우 서버는 HTTP 304 Not Modified 상태로 매우 짧은 응답을 반환할 수 있습니다.304 상태는 클라이언트에 캐시된 버전이 여전히 정상이며 이 버전을 사용해야 함을 알려줍니다.

단, ETag 값이 일치하지 않는 경우(리소스가 변경되었을 가능성이 있음)에는 ETag를 사용하지 않는 경우와 마찬가지로 리소스 내용을 포함한 전체 응답이 반환됩니다.이 경우 클라이언트는 이전에 캐시된 버전을 새로 반환된 리소스 및 새 ETAG로 바꾸기로 결정할 수 있습니다.

ETAG 값은 웹 페이지 모니터링 시스템에서 사용할 수 있습니다.대부분의 웹 사이트가 웹 페이지의 ETag 헤더를 설정하지 않기 때문에 효율적인 웹 페이지 모니터링이 방해됩니다.웹 모니터에 웹 컨텐츠가 변경되었는지 여부를 알 수 없는 경우 게시자와 구독자 모두를 위한 계산 리소스를 사용하여 모든 컨텐츠를 검색 및 분석해야 합니다.

불일치 ETAG 검출

버그가 있는 웹 사이트는 의미 리소스를 업데이트한 후 ETag를 업데이트하지 못할 수 있습니다.2019년 현재, 그러한 사이트의 예는 다음과 같다.export.arxiv.[4]org 를 참조해 주세요.그 결과, 잘못 반환된 응답은 스테이터스 304가 되어 클라이언트는 갱신된 자원을 취득할 수 없게 됩니다.이러한 버그를 검출하려면 , 다음의 순서에 따릅니다.

  • ETAG가 존재하며 응답이 중단되지 않았다고 가정하여 응답과 ETAG를 캐시합니다.
  • If-None-Match 헤더를 포함하는 후속 요청의 경우 20% 확률로 이 헤더를 전송하지 마십시오.이 경우 응답에서 변경된 콘텐츠가 반환되지만 이전에 캐시된 것과 동일한 ETAG가 반환될 경우 웹 사이트를 버그로 표시하고 ETAG 캐싱을 비활성화합니다.다시 한 번 강조하자면, 강력한 ETag의 경우 콘텐츠 비교는 바이트 대 바이트가 될 수 있지만 약한 ETag의 경우 의미적 동등성만 검사합니다.

ETAG를 사용한 트래킹

프라이버시 인식 유저에 의해서 HTTP 쿠키가 삭제되는 일이 증가하고 있기 때문에, ETAG 를 사용해 일의의 [5]유저를 추적할 수 있습니다.2011년 7월, Ashkan Soltani와 UC Berkeley의 연구팀은 Hulu를 포함한 많은 웹사이트가 추적 [6]목적으로 ETags를 사용하고 있다고 보고했습니다.Hulu와 KISSmetrics는 모두 2011년 [7]7월 29일부로 '재대응'을 중단했습니다.KISSmetrics와 그 클라이언트의 20개 이상이 ETAG [8]사용을 부분적으로 수반하는 '삭제할 수 없는' 추적 쿠키 사용에 대한 집단 소송에 직면해 있습니다.

ETAG는 브라우저에 의해 캐시되고 동일한 리소스에 대한 후속 요구와 함께 반환되므로 트래킹서버는 단순히 브라우저로부터 수신된 모든 ETAG를 반복하여 할당된ETAG가 (영속적인 쿠키와 같은 방법으로) 무기한 유지되도록 할 수 있습니다.추가 캐싱 헤더를 사용하면 ETAG 데이터의 [9]보존성도 향상됩니다.

ETAG는 브라우저 캐시를 클리어함으로써 플러시할 수 있습니다(실장은 다릅니다).

레퍼런스

  1. ^ "Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout". W3C Note. 10 May 1999.
  2. ^ "ETag – HTTP MDN". developer.mozilla.org. Retrieved 10 October 2021.
  3. ^ Mozilla. "Etag". Etag. Mozilla.
  4. ^ "Mismatched export.arxiv.org ETag".
  5. ^ "tracking without cookies". 17 February 2003.
  6. ^ "Flash Cookies and Privacy II: Now with HTML5 and ETag Respawning". 29 July 2011. SSRN 1898390. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  7. ^ "Respawn Redux". 11 August 2011.
  8. ^ AOL, Spotify, GigaOm, Etsy, KISSmetrics가 삭제할 수 없는 추적 쿠키에 대해 소송을 제기했습니다.
  9. ^ 쿠키리스 쿠키(ETAG를 쿠키로 사용)

외부 링크