Summary

  • HTTP 206 confirms successful delivery of one or more declared ranges from a selected representation; it does not by itself prove that separately retrieved ranges form one complete object.
  • Resumed transfers and cache assembly need one shared strong validator, exact interval coverage and a final representation-level integrity check.
  • Content-Length on a 206 response normally measures that response body, while Content-Range identifies its position and the selected representation's complete length.
  • A range-assembly receipt should preserve the representation identity and every accepted interval rather than treating a full byte count as sufficient evidence.

Imagine a routing-data archive being downloaded from object storage. The connection fails halfway through, and the client resumes with a request for the missing bytes. Between requests, the origin replaces the snapshot with a newer export of the same nominal size. Both requests return 206, every requested interval arrives, and the downloader reaches the expected byte count. Yet the reconstructed file contains the beginning of one representation and the end of another because no strong validator bound the retries together.

This is a hypothetical failure of assembly discipline, not an allegation against a storage provider. HTTP supplies the mechanisms needed to avoid it. The operating error is to ask a range response to prove more than its semantics provide.

A successful range has a bounded meaning

RFC 9110 defines 206 Partial Content as successful fulfilment of a range request by transferring one or more parts of the selected representation. The status is meaningful: the server accepted the request and returned the declared interval or intervals. It is not a declaration that the client now possesses the full representation.

A recipient must inspect Content-Type and each Content-Range field to determine what the response encloses and whether more requests are required. For a single byte range, Content-Range states the inclusive interval and usually the complete length of the selected representation. Content-Length, by contrast, normally counts the octets in the present 206 message content. Treating those two lengths as interchangeable can turn a correct partial response into a false completeness signal.

Multiple ranges add another bookkeeping obligation. A multipart response can return ranges in a different order from the request, and a server can coalesce or omit unsatisfiable ranges. Coverage therefore has to be calculated from the returned intervals, not inferred from request order, response count or a progress bar.

Continuity depends on the representation, not the URL

A stable URL does not mean the selected representation stayed unchanged between requests. Content negotiation, deployment, generation time or an origin update can alter the bytes while the target URI remains the same. Safe resumption needs evidence that old and new intervals refer to the same representation.

The If-Range mechanism exists for this boundary. A client with part of a representation can send a range request with a validator. If the validator still matches, the server can return the requested part. If it does not, the server ignores the Range field and sends the entire new representation. RFC 9110 forbids a client from using a weak entity tag in If-Range; the comparison requires the kind of validator that can distinguish representations suitable for byte-level combination.

This behaviour deserves explicit monitoring. A 200 response following an If-Range request is not an inefficient failure to be forced back into 206. It is evidence that the previous partial copy can no longer be safely extended. The correct action is to replace the old assembly state with the new full representation.

Last-Modified dates can serve as If-Range validators only under the standard's strong-validator conditions. In systems that generate more than one representation within a timestamp's resolution, an entity tag is usually clearer evidence. The choice is operational, but the receipt should record which validator was used and why it was considered strong.

Caches inherit the same obligation

RFC 9111 allows a cache to store incomplete responses and later complete them with range transfers under defined conditions. It also draws a hard line around recombination: ranges may be combined only when they share the same strong validator and the cache follows the partial-content combination rules.

That rule prevents a cache from manufacturing apparent completeness from unrelated fragments. It also means that cache hit ratios and stored-byte coverage are not enough for assurance. An operator needs to know the cache key and negotiation fields, the strong validator attached to each stored interval, whether headers were updated from the newest response, and whether the assembled response is fresh, validated or explicitly permitted to be served stale.

The same concern applies outside a formal HTTP cache. Download managers, package mirrors, media pipelines and object-store gateways all perform range assembly. If they persist fragments, they have created a cache-like evidence problem even when the product does not call the component a cache.

Check the proposition at the right digest layer

RFC 9530 separates two integrity scopes. Content-Digest is calculated over the content of the HTTP message. Repr-Digest is calculated over the entire selected representation data. That distinction matters for a 206 response: a digest of the returned segment can prove that segment's bytes arrived intact relative to the asserted digest, while a representation digest can validate the completed object reconstructed across requests or connections.

Neither field removes the validator requirement. The validator establishes whether fragments are versions of the same selected representation; the final Repr-Digest checks the assembled representation's bytes. Interval coverage proves that there are no gaps or overlaps hidden by a total counter. Together they support a stronger claim than any one signal alone.

Digest fields also do not define authentication, authorization or privacy. If the business question includes who was entitled to publish the representation, the digest assertion needs an authenticated channel or a separately verified signature and key-authority record. R063 stays at the narrower assembly boundary: whether the retrieved bytes form one coherent representation.

Build a range-assembly receipt

The practical evidence object is a range-assembly receipt. Start it when the first partial response is accepted. Record the target URI, method, request headers that affect selection, content encoding, media type, complete length, strong validator, observation time and whether the response came from an origin, intermediary or local store.

For every accepted part, record the returned interval, response status, validator, source, cache status and segment digest when available. Maintain a normalized interval set so overlaps do not inflate progress and gaps remain visible. Reject an interval when its validator or representation metadata conflicts with the frozen assembly identity.

Close the receipt only when the intervals cover the selected representation exactly and the reconstructed bytes pass the expected Repr-Digest or another independently obtained representation hash. If the strong validator changes, becomes unavailable or proves ambiguous, discard the mixed assembly and retrieve a complete current representation. That can cost bandwidth. It protects the more valuable claim that the object being processed actually existed as one representation.

Sources