Overview

Digest carries a cryptographic checksum of the message's selected representation (usually the body) so integrity can be verified in transit. It can appear on both requests and responses.

The value is `algorithm=base64-checksum` (e.g. `sha-256=...`), and its companion Want-Digest lets a client ask the server to include a digest computed with a specific algorithm.

Details

It was introduced as the successor to the obsolete Content-MD5, and the IETF 'Digest Fields' work later redefined Digest/Want-Digest into Content-Digest, Repr-Digest, Want-Content-Digest, and Want-Repr-Digest. The newer spec changes the value encoding to a structured-fields byte sequence (`:...:`), so you must confirm whether the peer implements the legacy Digest or the newer Content-Digest.

Integrity verification is the point. For large uploads/downloads, traffic through caching proxies, or proxy reassembly, the receiver recomputes and compares to detect corruption of the body. Using a strong hash like sha-256 is far more trustworthy than md5.

Digest is only an integrity signal, not authentication by itself. An attacker who can rewrite the body can also rewrite the Digest, so authenticity is provided by HTTPS (TLS) or a signing mechanism such as HTTP Message Signatures. Digest becomes strong when it is what such a signature protects.

Syntax

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

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

Notes

• An ETag is an opaque cache-validation identifier; a Digest is an actual content hash. They serve different purposes — don't substitute one for the other.
• Legacy Digest/Want-Digest and the newer Content-Digest/Repr-Digest differ in encoding and meaning. Specs also differ on whether the hash is over the content before or after encoding (gzip), so be careful.
• Without TLS, Digest alone cannot prevent tampering: integrity is a separate concern from authenticity.

Related headers

Specification