Want-Unencoded-Digest

Verifying decoded data calls for a digest computed before content coding. The Want-Unencoded-Digest request and response header signals preference for an Unencoded-Digest hash covering the representation with no content codings applied.

Table of Contents

Draft specification

Want-Unencoded-Digest is defined in the HTTP Unencoded Digest Internet-Draft. The document has been approved for publication as a Proposed Standard and is in the RFC Editor queue. The field name holds a permanent IANA registration since June 2026.

Usage

The Want-Unencoded-Digest header indicates which hashing algorithms the sender prefers and supports for integrity verification of the unencoded representation. The server reads this header and decides whether to include an Unencoded-Digest header in the response with a hash computed using one of the requested algorithms.

This header extends the HTTP integrity preference fields alongside Want-Content-Digest and Want-Repr-Digest. The Unencoded-Digest field provides a hash of the selected representation before any content coding is applied. This differs from Repr-Digest, which covers the representation data including its content coding, and from Content-Digest, which covers the content of the current message.

Clients use this header when they verify data after transparent decoding, such as JavaScript checking a downloaded file the browser already decompressed. When the header appears in a response, it indicates the server would like the client to provide an Unencoded-Digest field on future requests. The header is a hint. The receiver is free to respond with any algorithm or omit the digest entirely, and ignored preferences are an application-level concern rather than a protocol error.

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-Unencoded-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 sender does not accept the algorithm.

Example

A client requesting a SHA-256 digest of the unencoded representation with a preference weight of 1. The server includes an Unencoded-Digest header in the response using the requested algorithm.

Want-Unencoded-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-Unencoded-Digest: sha-512=3, sha-256=10, unixsum=0

A server responding with the requested digest. The response is delivered with gzip content coding, yet the hash covers the bytes before coding, so the client verifies the decoded data without re-encoding it.

Request

Want-Unencoded-Digest: sha-256=10

Response

Content-Encoding: gzip
Unencoded-Digest: sha-256=:5Bv3NIx05BPnh0jMph6v1RJ5Q7kl9LKMtQxmvc9+Z7Y=:

See also

Last updated: August 11, 2026