Want-Repr-Digest
The HTTP Want-Repr-Digest request and response header signals preference for a Repr-Digest hash in the message, allowing verification of the representation integrity before any content encoding.
Usage
The Want-Repr-Digest header indicates which hashing algorithms the client prefers and supports for representation integrity verification. The server reads this header and decides whether to include a Repr-Digest header in the response with a hash computed using one of the requested algorithms.
This header is part of the HTTP integrity framework, which replaced the older Want-Digest header. The Repr-Digest field provides a hash of the selected representation before any content encoding gets applied. This differs from Content-Digest, which hashes the message content after content encoding.
Clients use this header when the canonical representation hash matters more
than the transmitted bytes. A response sent with
Content-Encoding: gzip produces different
Content-Digest and Repr-Digest
values. The Content-Digest hashes the encoded bytes,
while the Repr-Digest hashes the original unencoded
representation.
The header uses a dictionary format where each algorithm name maps to a preference weight from 0 to 10. A weight of 10 indicates the highest preference, 1 indicates the lowest preference, and 0 means the algorithm is explicitly not acceptable.
Directives
The Want-Repr-Digest header uses algorithm identifiers as keys and integer preference weights as values. Multiple algorithms are separated by commas.
sha-256
The sha-256 algorithm requests a SHA-256 hash digest. SHA-256 produces a
256-bit hash and is widely supported across HTTP implementations.
sha-512
The sha-512 algorithm requests a SHA-512 hash digest. SHA-512 produces a
512-bit hash and offers stronger collision resistance than SHA-256 at the
cost of larger digest size.
Preference weights
Each algorithm is followed by an equals sign and an integer from 0 to 10. Higher values indicate stronger preference. A value of 0 signals the client does not accept the algorithm.
Example
A client requesting SHA-256 representation integrity verification with a preference weight of 1. The server includes a Repr-Digest header in the response using the requested algorithm.
Want-Repr-Digest: sha-256=1
A client expressing preference for SHA-512 with a fallback to SHA-256. The
weight of 10 for SHA-256 and 3 for SHA-512 indicates SHA-256 is strongly
preferred. The unixsum=0 entry explicitly rejects the legacy Unix checksum
algorithm.
Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0
A server responding with a representation digest. The client expressed a stronger preference for SHA-256 (weight 10) over SHA-512 (weight 3). Servers are not bound by client preferences. They use whichever algorithm they support, or none at all. Here the server chose SHA-512. The hash represents the uncompressed representation, even though the response body is delivered with gzip compression.
Request
Want-Repr-Digest: sha-512=3, sha-256=10
Response
Content-Encoding: gzip
Repr-Digest: sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCsyRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
Takeaway
The Want-Repr-Digest header signals algorithm preferences for representation integrity verification, requesting the server include a Repr-Digest hash computed before any content encoding gets applied.