Unencoded-Digest

Verifying data that arrives through transparent decompression requires a digest of the bytes before any coding was applied. The Unencoded-Digest request and response header carries an integrity digest computed over the selected representation with no content codings applied.

Table of Contents

Draft specification

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 Unencoded-Digest header conveys a digest calculated over the entire selected representation data with no content codings applied. The field appears in requests and responses, and in trailer sections when the digest is computed while streaming.

The header completes the HTTP integrity framework alongside Content-Digest and Repr-Digest. Content-Digest hashes the message content as transmitted, which is partial for range responses. Repr-Digest hashes the representation data, which includes any content coding applied to it. Unencoded-Digest hashes the same representation before any coding, giving recipients a value to check against decoded bytes directly. When a message carries no content coding, Unencoded-Digest and Repr-Digest produce identical values for the same algorithm.

The problem the header solves appears wherever decoding happens transparently. Browsers hand JavaScript the decoded response body, so checking a Repr-Digest over gzip-coded bytes would require re-encoding the data with the exact same coding, an operation needing extra libraries and matching encoder settings. Some codings are designed for fast decoding at the cost of expensive encoding, and a chain of multiple codings compounds the work. Unencoded-Digest lets the recipient hash the bytes it already holds.

Range request reconstruction is the second driver. A client stitching together partial responses compares one Unencoded-Digest value against the reassembled whole, even when individual responses used different content codings. The Repr-Digest value shifts with each response's selected coding, while Unencoded-Digest stays constant for the same underlying data.

The header uses the Structured Fields Dictionary format. Each key names a hashing algorithm from the digest algorithm registry, and each value is a Byte Sequence carrying the digest output. Multiple algorithms appear in one header to support endpoints with different capabilities or to migrate away from weaker algorithms. Recipients are free to ignore any or all of the conveyed digests.

Clients ask for the header with Want-Unencoded-Digest, which carries weighted algorithm preferences. When a message arrives with content codings, the recipient decodes the content first and then computes the digest over the decoded bytes. With multiple codings, all are removed in order before validation. Validation succeeds when decoding reproduces the original bytes exactly, which holds for most registered content codings.

Note

Validating Unencoded-Digest on coded content means feeding received bytes into a decoder before any integrity check has passed. Pairing the header with Content-Digest or Repr-Digest allows validation of the received bytes before decoding. With encrypting content codings such as aes128gcm, the digest reveals information about the plaintext, so the field is treated as sensitive and omitted unless the field itself is encrypted.

Algorithms

sha-256

The sha-256 algorithm produces a 256-bit digest using the SHA-256 cryptographic hash function. This algorithm suits most integrity verification needs and is widely supported.

sha-512

The sha-512 algorithm produces a 512-bit digest using the SHA-512 cryptographic hash function. This algorithm provides stronger cryptographic properties for contexts requiring additional security margin.

Example

A server responds with gzip content coding. The representation before coding is the text "An unexceptional string" followed by a line feed. The Repr-Digest covers the gzip-coded bytes, while the Unencoded-Digest covers the original text, so the two values differ.

Content-Type: text/plain
Content-Encoding: gzip
Repr-Digest: sha-256=:kwcdt3RBGcsLaj7QSz9AW8MuwJaLjOJqUU/jKixF2oU=:
Unencoded-Digest: sha-256=:5Bv3NIx05BPnh0jMph6v1RJ5Q7kl9LKMtQxmvc9+Z7Y=:

A partial content response to a range request carries all three integrity fields. The Content-Digest validates the received part immediately. The Repr-Digest and Unencoded-Digest validate the complete object once all parts are reassembled, against the coded and uncoded bytes respectively.

HTTP/1.1 206 Partial Content
Content-Type: text/plain
Content-Encoding: gzip
Content-Range: bytes 0-9/44
Content-Digest: sha-256=:SotB7Pa5A7iHSBdh9mg1Ev/ktAzrxU4Z8ldcCIUyfI4=:
Repr-Digest: sha-256=:kwcdt3RBGcsLaj7QSz9AW8MuwJaLjOJqUU/jKixF2oU=:
Unencoded-Digest: sha-256=:5Bv3NIx05BPnh0jMph6v1RJ5Q7kl9LKMtQxmvc9+Z7Y=:

Multiple algorithms appear when endpoints with different capabilities consume the same responses. The recipient selects the strongest recognized algorithm and verifies the decoded bytes against the corresponding digest value.

Unencoded-Digest: sha-256=:5Bv3NIx05BPnh0jMph6v1RJ5Q7kl9LKMtQxmvc9+Z7Y=:, sha-512=:WjyMuMD9EI/v0RoJchcevbo6lF498VyE9564OgXf+98iJptoSvb1Czo9uVJu2bVU/tOv90huiMG3+YaMX1kipw==:

See also

Last updated: August 11, 2026