The direct answer
Record which exact bytes the digest check covers before calling an artifact verified. For a partial response, Content-Digest concerns that message’s content, while Repr-Digest concerns the entire selected representation. Keep a successful tail check separate from complete-artifact verification, trusted metadata and current access rights.
Replace the verified badge with a byte-domain question
An AI document worker resumes an interrupted artifact transfer. The six-octet tail passes a digest check, so its interface marks the whole document verified. That label hides which input the verifier actually checked and whether the earlier prefix belongs to the same approved artifact.
This worksheet selects one known, uncoded representation, an admitted prefix and one single-part tail response. It excludes multipart bodies, content-coding alternatives, automatic decoding, trailers, redirects and recovery loops. Those exclusions define the teaching profile; they do not declare other HTTP features invalid.
All examples and eight cards are PROPOSED_UNRUN. No bytes, digest values, HTTP fields, client, request, hash, parser or runtime fixture was constructed or exercised. The labels represent evidence requirements, not downloaded content or cryptographic results.
Name the two integrity inputs precisely
RFC 9530 sections 2 and 3 define Content-Digest over actual message content and Repr-Digest over the entire selected representation data. Its partial-response example in Appendix B.3 gives different values because the response carries only a range while the representation digest covers the whole selection.
For our application, store the field name and intended coverage with every verification disposition. A boolean called checksum_ok cannot distinguish a successful check of one received segment from a supported check of the finished artifact. A supplied expected value and a completed comparison also belong in different fields.
The actual complete field reader, accepted algorithm policy and verifier are unimplemented prerequisites. This article supplies no structured-field decoder or algorithm choice. If an implementation cannot establish what it read or which bytes it checked, hold the integrity claim instead of selecting a convenient interpretation.
Map the response onto the selected representation
RFC 9110 sections 6.4, 14.1.2 and 15.3.7.1 distinguish message content after framing from the representation. Byte offsets start at zero and include both endpoints. A single-part 206 carries the range described by Content-Range. With content coding, offsets refer to coded representation bytes.
The selected plan needs independently supported evidence that counted, staged and verified octets are the same uncoded octets. Merely requesting a preferred encoding or seeing a familiar media type cannot establish the effective client path. Unknown transformation behavior keeps the plan unsupported.
The resume guide still governs selection, strong-validator continuity and complete range assembly. This new integrity check does not replace that contract, authorize another request or permit mixing bytes from different revisions.
Use an original four-plus-six integrity sheet
Invent artifact A-A with complete length ten octets. Its admitted prefix occupies positions 0–3; the proposed tail occupies 4–9. H-T is a symbolic expected tail-content digest reference; H-F is a symbolic independently trusted full-representation baseline. Neither is an actual hash or encoded field value.
| Decision | Verifier input required by this plan | Claim boundary |
|---|---|---|
| Tail content | The actual six-octet single-part response content, under its supported metadata association | Only that tail input’s integrity disposition |
| Complete representation | The complete same-selection ten-octet assembly against accepted H-F | The declared full-byte integrity disposition |
| Release | Complete assembly, trusted provenance, permitted content and current rights | Eligibility for separate parser/application admission |
A supported H-T comparison cannot inspect the four prefix octets that were not in its input. Likewise, possession of H-F does not mean the receiver has performed the full comparison. Preserve missing-input status rather than using the field’s name as the result.
The useful positive requires accepted continuity, exact bounded assembly and a supported full-input comparison against the trusted baseline. The six-octet check may be useful evidence about the transfer, but the complete artifact gets its own disposition. This worksheet supplies no shortcut for combining segment digest values into a full check.
Bind expected values and metadata to actual trust
RFC 9530 sections 6.1–6.3 explain that integrity fields do not themselves protect HTTP metadata or provide general authentication. An attacker able to replace both data and its digest defeats an unsupported authenticity claim. Representation metadata matters to the interpretation.
Our proposed baseline record therefore binds approved artifact revision, representation selection, relevant metadata, expected full-byte value, permitted algorithm and trust source. An expected value copied automatically from an untrusted reply is not an independently accepted artifact baseline. Actual authentication and metadata protection need their own reviewed mechanism; none is implemented here.
Require that association to survive staging and handoff. A later object replacement or silently changed selection must not inherit an earlier success record. Record minimal revision, coverage, verifier and disposition references rather than copying document content into diagnostics.
Walk eight inert integrity cards
| Condition | Proposed disposition |
|---|---|
| 1. Complete A-A assembly, trusted H-F, supported full-byte verification and all current prerequisites hold | Conditionally admit only that exact integrity claim for later release checks. |
| 2. Only the tail-content check succeeds | Record limited coverage; no whole-artifact verification. |
| 3. Full-representation value exists but required prefix bytes are missing | Keep full verification unestablished. |
| 4. Selection, validator, interval or total differs | Hold continuity regardless of a check on the changed reply. |
| 5. Field scope, algorithm or expected-value trust is unknown | Withhold the selected integrity claim; no guess or fallback. |
| 6. Transformation changes the verifier’s byte domain | Outside this uncoded profile; do not reuse the old expectation. |
| 7. Untrusted source supplies matching data and digest | No authenticated provenance or approved-baseline inference. |
| 8. Integrity matches but current data rights or content admission fails | Withhold release independently. |
State the missing evidence and the product limit
Actual baseline authenticity, supported field parsing and algorithm policy, preserved capture, complete range assembly, immutable staging, bounded verification and current rights are unimplemented and unknown. Any missing required premise blocks a real positive. A match does not establish harmless instructions, parser safety, storage durability or permission to disclose material to a model.
The selected sources are February 2024 RFC 9530 and June 2022 RFC 9110, both Standards Track. No installed client or server behavior was observed. Boundary remains prelaunch with planned request-path checks, not a shipped artifact-integrity service. Its existing mock-policy evidence does not validate these proposed checks.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.