Separate coding from framing
03Content coding changes representation bytes. Transfer framing carries those bytes but is not part of the digest input.
A sender can stream bytes and send an Integrity field in a trailer. This validating application waits for that value before trusting the content; trailers can be dropped by intermediaries.
Source for this drawing: RFC 9530 · Read RFC section 6.5 ↗
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.
Content-Digest and Repr-Digest depend on representation metadata such as Content-Encoding and Content-Type. For a full gzip-coded response, hash the coded bytes rather than silently decompressing first.
- Content-Digest and Repr-Digest depend on representation metadata such as Content-Encoding and Content-Type. For a full gzip-coded response, hash the coded bytes rather than silently decompressing first.
- HTTP/1.1 chunk sizes, delimiters and trailer framing do not enter the content or selected-representation hash. Removing transfer framing is different from removing content coding.
- Even the same Content-Encoding value can produce different encoded bytes. Retain the actual coded data when it is needed for later validation; the coding name alone is insufficient.
Gzip is a content-coding format. These are bounded coding/framing examples, not an HTTP chunk parser. Reported erratum 8890 concerns the RFC’s Brotli examples; these drawings use independently verified gzip bytes instead. Verified editorial errata 8158/8273 are distinguished in author evidence.
Read the RFC section ↗