Want-Repr-Digest

When a hash of the complete resource matters more than a hash of the bytes in a single message, the Want-Repr-Digest request and response header signals preference for a Repr-Digest hash covering the entire selected representation.

Table of Contents

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 entire selected representation, including any content encoding applied to it. This differs from Content-Digest, which hashes only the content conveyed in the current message.

Clients use this header when a hash of the complete resource matters more than the bytes of a single message. A partial-content response to a range request produces different Content-Digest and Repr-Digest values. The Content-Digest hashes only the transferred portion, while the Repr-Digest covers the whole representation, staying stable across range requests and HEAD responses. Content encoding forms part of the representation data, so serving the same resource with a different coding changes the Repr-Digest value.

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-256 with a fallback to SHA-512. 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 response is delivered with gzip content coding, and the hash covers the gzip-coded representation, since content encoding forms part of the representation data.

Request

Want-Repr-Digest: sha-512=3, sha-256=10

Response

Content-Encoding: gzip
Repr-Digest: sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCsyRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:

See also

Last updated: August 11, 2026