Key takeaway
Pin the representation across range requests and inspect every response. Equal length and complete byte offsets do not establish that the assembled file ever existed as one approved version.
The same address can return a different object
A receiver downloads half a package, loses the connection and resumes later using the same URL. During the gap, the owner replaces the object at that address. If the receiver blindly appends the new range, it can assemble a file that belongs to neither release. An orderly coverage ledger can contain every expected byte offset and still describe this mixed-version artifact.
RFC 9110 says partial responses can be safely combined when they share the same strong validator. That is a representation-identity condition, beyond knowing the requested ranges. A strong validator is not automatically a whole-file checksum; the delivery process must retain what the server’s validator actually means and keep an approved object identity beside it.
An eight-byte hypothetical package that never existed
Let approved version A consist of the eight ASCII bytes ABCDEFGH. A later version B at the same address consists of 12345678. The first response supplies offsets 0–3 of A, namely ABCD. After replacement, an unconditional retry supplies offsets 4–7 of B, namely 5678. Appending them produces ABCD5678: eight bytes, complete offsets, and neither source version.
These invented strings and version labels are a local assembly illustration, not actual HTTP responses or cloud object identifiers. The author reconstructed the slices and compared the complete strings. A final approved full-file checksum can expose the mismatch if it is actually verified, but it does not make cross-version assembly an acceptable receiving procedure.
| Synthetic receiving event | Returned content | Representation evidence | Assembly decision |
|---|---|---|---|
| First range 0–3 | ABCD | Version A / strong validator A | Retain as partial A |
| Unconditional retry 4–7 after replacement | 5678 | Version B / strong validator B | Do not append to A |
| Both ranges pinned to A | ABCD and EFGH | Same approved version and validator | Assemble A; then verify full artifact |
| False generic HTTP If-Range | Full new representation may be returned | Inspect status and identity | Restart only within approved version policy |
A conditional retry can change the response shape
For generic HTTP, If-Range requests the range when its validator matches. When it does not, the server ignores Range and can return the entire new representation with 200 rather than the expected partial 206. A client must inspect that status and replace or quarantine its partial state appropriately. Appending a full response to the old prefix creates another corrupted assembly.
RFC 9110 prohibits a weak entity tag in If-Range. Its partial-content rules also require inspecting Content-Range rather than assuming the request describes what arrived. Record the returned offsets, total size and representation identity on each response. An unexpected status, gap, overlap or inconsistent total should trigger the receiving procedure’s explicit hold or restart path.
Use the object store’s actual supported identity mechanism
Amazon S3 GetObject normally returns the current object version; an available versionId selects a specific version. Its If-Match parameter instead returns the object only for the specified ETag and gives 412 Precondition Failed on mismatch. Those documented mechanisms are different from assuming S3 implements generic If-Range. Use the actual API contract rather than transplanting an unsupported header.
Version retrieval depends on bucket capabilities, retained versions and the caller’s permissions. The cited API notes that directory buckets do not support S3 Versioning in the same way. Do not change an account, enable versioning or request broader access as an automatic consequence of a failed download. Establish a supported approved delivery path with the owner.
In the fictional example, pinning A is useful only if A is still the intended approved package and remains retrievable. A server returning B consistently does not transfer approval to B. A correction or replacement package needs its own release identity and handling decision. Keep the technical retry state separate from permission to receive a revised scope.
Close the transfer with both identity and coverage
The completed example rejects ABCD5678 and accepts only an assembly whose ranges all belong to approved A, subject to the remaining full-file checks. Its receipt records the package reference, supported object/version selector, strong-validator evidence where applicable, requested and returned ranges, statuses, returned totals, restart decisions and final checksum comparison. Avoid retaining secret-bearing download URLs in that record.
Test this behavior with a synthetic object that changes between two reads, a false conditional request and a full response to a range request. A successful uninterrupted download does not exercise those boundaries. This fixture complements the checksum guide: one controls which representation is assembled; the other compares the completed byte scope against the trusted expected artifact.