Define the representation
A byte range refers to part of a selected HTTP representation. Start with a stable owned media asset and its published revision. If bytes at the same address change during a viewing session, requests for different parts can refer to different versions unless the delivery design handles that relationship.
Write the origin's intended behaviour for full requests, satisfiable ranges and unsatisfiable ranges. Include intermediary behaviour if a CDN or proxy is part of the authorised publishing path. Do not infer the entire policy from a single header on the homepage.
Review the actual response
HTTP defines partial-response semantics, including Content-Range for relevant responses. Inspect status, range metadata and returned bytes together. A request containing a Range field is not by itself proof that the response contains only that range.
For a hypothetical 1000-byte fixture, select simple intervals whose expected content can be checked independently. Use a fixture under your control rather than repeatedly downloading a private commercial programme. Keep the request and response evidence with the asset revision.
Test the viewing tasks separately
A file can start while seeking behaves differently. Review beginning playback, a later position and an invalid interval using the intended client when performing acceptance. Network delivery and container indexing both matter to the overall task; a valid partial response does not certify that a media file is seekable at every arbitrary instant.
If a full response arrives instead, record it accurately and investigate the origin and intermediaries. Do not automatically call it an access failure, empty file or codec error. The correction depends on the publishing contract and client requirement.
Keep replacements coherent
Use appropriate validators and a deliberate revision strategy for changing assets. Preserve the old version long enough for any intended session continuity, or use versioned addresses when that fits the application. Never splice newly exported bytes into a resource clients still treat as the old file.
After a publishing change, repeat the bounded range checks and the original media task. Keep transport results separate from playback results and state untested destinations. This provides a useful handoff for the origin operator without claiming that one request validates the entire player.
Questions answered
Does a Range request guarantee a 206 response?
No. Inspect the actual status and returned representation rather than inferring response behaviour from the request.
Does successful partial delivery prove correct video seeking?
No. Container structure, timing and the client also affect the viewing task.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.