개요

Digest는 메시지의 선택된 표현(주로 본문)에 대한 암호학적 체크섬을 전달해, 전송 중 무결성을 검증할 수 있게 하는 헤더입니다. 요청·응답 양쪽에서 쓸 수 있습니다.

값은 `알고리즘=base64체크섬` 형태이며(예: `sha-256=...`), 클라이언트는 짝인 Want-Digest로 서버에 특정 알고리즘의 다이제스트를 요청할 수 있습니다.

자세히

폐기된 Content-MD5의 후계로 도입되었고, 이후 IETF의 'Digest Fields' 작업에서 Digest/Want-Digest는 다시 Content-Digest·Repr-Digest·Want-Content-Digest·Want-Repr-Digest로 재정의되었습니다. 새 명세는 값 표기를 구조화 필드(structured fields)의 바이트 시퀀스(`:...:`)로 바꾸는 등 형식이 다르므로, 상대 구현이 구형 Digest인지 새 Content-Digest인지 확인해야 합니다.

무결성 검증이 핵심 목적입니다. 대용량 업로드·다운로드, 캐싱 프록시 경유, 프록시 재조립 과정에서 본문이 손상되지 않았는지 수신 측이 재계산해 비교합니다. sha-256 같은 강한 해시를 쓰면 md5보다 신뢰도가 높습니다.

Digest는 무결성(변조·손상 탐지) 신호일 뿐 그 자체로 인증이 아닙니다. 공격자가 본문과 Digest를 함께 바꿀 수 있으므로, 진위 보장은 HTTPS(TLS)나 HTTP Message Signatures 같은 서명 메커니즘이 담당합니다. Digest는 그런 서명이 보호하는 대상이 될 때 강해집니다.

문법

Digest: <algorithm>=<base64-value>[, ...]

e.g. Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=

실무 참고

• ETag는 캐시 검증용 불투명 식별자이고 Digest는 실제 콘텐츠 해시입니다. 목적이 다르므로 서로 대체하지 마세요.
• 구형 Digest/Want-Digest와 신형 Content-Digest/Repr-Digest는 표기·의미가 다릅니다. 인코딩(gzip) 적용 전후 중 무엇을 해시했는지도 명세마다 다르니 주의하세요.
• TLS 없이 Digest만으로는 위·변조를 막지 못합니다. 무결성은 진위(authenticity)와 다른 문제입니다.

관련 헤더

스펙 근거