The direct answer
Extend a partial download only when the response belongs to the same authorized representation and supplies exactly the missing octets under the chosen contract. Never append a full 200 response to an old prefix or treat 416 as proof of completion. Keep the assembled result unavailable to an AI parser until continuity, bounds and current access checks pass.
Make the decision about bytes, before parsing
A document fetcher has four octets from an interrupted transfer. Its next response contains six octets. That arithmetic alone cannot establish a complete ten-octet document: the bytes might belong to another version, selection or resource.
This original protocol worksheet asks whether one restricted checkpoint may be completed. It differs from conditional writes, cache revalidation and download-link lifetime. No HTTP client, automatic decoding behavior or storage implementation is selected. All labels and outcomes below are PROPOSED_UNRUN; there is no downloaded object or byte payload.
Separate HTTP semantics from the narrower admission policy
RFC 9110, sections 14.1.2 and 13.1.5, defines zero-based inclusive byte offsets over representation data, including content coding when present. If-Range uses strong entity-tag comparison; a false condition makes the recipient ignore Range. Weak tags are forbidden there; constrained date use also exists.
Sections 14.2 and 14.3 allow Range to be ignored and make advertised support non-guaranteeing. Sections 14.4 and 15.3.7 require interpreting the returned range; 206 can supply less than requested. Its Content-Length concerns that response content. Combining parts requires a common strong validator. Normal checks and detectable failures precede condition evaluation under section 13.2.
Our stricter policy permits only one single-part GET tail, a known total and a previously established unencoded selection. It excludes date fallback, multipart, suffix ranges, redirects and automatic compatibility retries. A compliant response can still fall outside this application profile; “unsupported here” does not mean invalid HTTP.
Bind the checkpoint before considering a response
Invent checkpoint C-A for resource R-A at approved origin O-A, within workspace W-A. Its protected record binds selection SEL-A, original response metadata, supported strong validator TAG-A, complete length ten octets and accepted prefix positions 0 through 3. Keep the prefix immutable relative to that record. A model-suggested URL, tag or length cannot replace the approved association.
SEL-A includes the reviewed representation-selection inputs and the unencoded-byte prerequisite. Preserve relevant prior metadata rather than inventing it when a later response omits fields. RFC 9110 section 15.3.7 permits reduced representation metadata with If-Range. This worksheet nevertheless requires sufficient supported selection evidence; uncertainty means hold, not an assumption that missing Content-Encoding proves unchanged bytes.
Requesting identity encoding alone would not demonstrate the effective server or client path. Before implementation, establish that the octets counted and staged are the representation octets described by the offsets, without an intervening transformation. That prerequisite remains unverified here. Do not substitute text characters, decoded length or transfer-framing bytes.
Work through the useful four-plus-six case
The intended remainder is positions 4 through 9: 9−4+1=6 octets. The positive card assumes current authority for R-A, checkpoint C-A unchanged, the same supported SEL-A/TAG-A evidence, and a single-part 206 describing interval 4 through 9 of total ten. The actual accepted response-content count must be six; an asserted length is insufficient.
Stage that segment separately while checking the card. Require the supported media-type interpretation to be single-part, exact interval endpoints, known total ten and no contradictory metadata. This profile rejects a shorter valid partial response rather than silently adding another recovery branch. Unknown units, unknown totals and missing required validator evidence do not pass.
Only the contiguous union 0 through 9 can complete this worksheet: four accepted prefix octets plus six accepted tail octets, with no gap, overlap or replacement. Even a ten-octet combined count is insufficient if the associations differ. A strong validator is resource-scoped, not a global object identifier (RFC 9110 section 8.8.1).
Review eight inert response cards
| Inert observation | Proposed disposition |
|---|---|
| Same approved resource, selection and strong tag; 206 interval 4–9, total ten, actual count six | Eligible for complete ten-octet staging after every remaining gate |
| TAG-B, weak or absent required tag evidence, or changed selection | Hold; never splice into the TAG-A prefix |
| 206 starts at five, overlaps the prefix, changes total or disagrees with actual count | Reject for this exact-tail contract; do not repair by blind append |
| Full 200 response arrives | Never append; discard the old assembly and require a separately authorized, bounded fresh-transfer path |
| 416, with or without reported current length | Keep incomplete; reconcile identity and length without declaring local completion |
| Access revoked, wrong workspace, denial, redirect or resource failure | No extension or disclosure; a matching tag cannot restore authority |
| Encoding, transformation or counted-byte interpretation differs or is unknown | Unsupported; do not reuse earlier offsets against those bytes |
| More than six tail octets, truncated transfer, exhausted attempt allowance or expired checkpoint | Stop and withhold completion; never trim, pad or reset the allowance |
RFC 9110 section 15.5.17 describes 416 as rejected ranges, not evidence about local coverage. Its reported length cannot certify the saved prefix. A full response is a separate representation transfer, not the missing tail.
Release only a complete, still-authorized assembly
For this invented exercise, cap accepted assembly at ten octets, allow one tail attempt and give the checkpoint a short explicitly configured lifetime. These are teaching choices, not measured production defaults. A future implementation must bound incoming work and staging before excess allocation; rejecting after unlimited buffering would not establish that boundary.
Coordinate checkpoint identity, accepted segment commitment and the current-rights release decision through a supported design. A separate check followed by an unprotected write or disclosure can race replacement or revocation. No store transaction, client preservation guarantee or complete resource-control mechanism is established by this worksheet.
Completion does not authenticate a producer, establish benign content or authorize provider disclosure. Apply separate artifact and parser admission afterward. Keep minimized checkpoint/revision, interval, count and disposition evidence rather than document contents.
No range request, header construction, download, client/runtime fixture, crypto or model experiment occurred for these cases. Boundary is prelaunch and does not claim a shipped resumable-download service. The eight historical mock policy checks and separate synthetic JSON-export checks establish different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.