Choose the right input
02Content-Digest covers message content. Repr-Digest covers the entire selected representation data, even when this message carries none or only a range.
After obtaining all compatible ranges of the same selected representation, the client can reconstruct 19 bytes and recalculate Repr-Digest. Digest fields do not replace range or validator checks.
Source for this drawing: RFC 9530 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
With a full selected representation as content, both fields can have the same value. They need not always differ.
- With a full selected representation as content, both fields can have the same value. They need not always differ.
- A HEAD response has no content: Content-Digest can hash the empty input while Repr-Digest hashes the selected representation.
- For a single-range response, Content-Digest hashes the returned content and Repr-Digest hashes the whole selected representation. A slice alone is not enough to recalculate the whole digest.
The range geometry is to scale for 19 bytes. Examples assume compatible data for one selected representation; HTTP range and validator semantics still apply. A multipart response requires its actual content semantics, not this single-range shortcut.
Read the RFC section ↗