Accept resumed downloads without splicing different editions

Define the object before testing interruption

MDN’s HTTP range-request guide, checked 7 November 2026, describes 206 partial responses and conditional If-Range requests. When the condition does not hold, the response supplies the full representation instead. Content-Range identifies the returned interval. These facts support a continuation-versus-replacement decision, not an assumption that every successful response can be appended.

Choose a synthetic public resource large enough to exercise the intended workflow without using real customer material. Give its beginning, middle and end recognizable invented markers, and preserve an intact approved copy. Record the edition and the identity evidence the technical owner will use for comparison. A recognizable final paragraph is useful to a reviewer, but it should complement rather than replace the owner’s complete-object comparison.

Preserve the interrupted state as evidence

Ask the implementation owner to supply a controlled interruption fixture with a known retained portion. Record what the receiving client believes it has, the approved object it belongs to and the point at which the exercise stopped. Do not clear the partial state before reproducing the issue. Starting again with a clean full download would demonstrate a different path and could conceal the defect under review.

Inspect the proposed continuation evidence with the owner. Separate the requested portion from the portion actually returned, and distinguish an entire replacement from the expected continuation. Keep the raw technical observations with a plain-language explanation for the release reviewer. The evidence should make it possible to explain why a client retained, replaced or discarded previous material without relying on the final progress indicator.

In a fictional 1,000-byte fixture, the client retains bytes 0–399. A supplied 206 covering 400–999 can be assessed as continuation. A supplied 200 containing a complete revised object is a replacement candidate, not another 1,000 bytes to append. Compare the resulting object before acceptance.

Exercise an edition change deliberately

Use a second invented edition that differs in a meaningful middle section, not merely in its displayed name. Have the owner supply the intended interrupted-transfer outcome when that edition becomes the approved object. The review must establish whether the receiving workflow continues the original edition, starts the new one or holds an unresolved result. Do not let an ambiguous mixture masquerade as either approved edition.

Compare the reconstructed artifact with the appropriate intact fixture through the qualified owner’s supported method. Check the reader-facing result as well: can it be opened normally, does its stated edition match its contents and is the revised section present where expected? A file that opens is not automatically complete or internally consistent. Keep the changed-edition case separate from a simple connection interruption in which the intended object never changed.

Document restart and recovery honestly

Define what the reader should be told when the saved progress cannot be reused safely. The wording should explain the practical consequence without exposing internal diagnostics or implying that the reader caused the problem. Avoid a promise that all progress survives every interruption. If the system cannot establish the identity of the retained object, a deliberate restart may be preferable to presenting an uncertain artifact as complete.

Retain the interruption fixture, response observations, continuation decision and final comparison as one acceptance packet. Repeat it when delivery infrastructure or client download behavior changes. Do not authorize live header changes from the lesson itself; route implementation decisions through the responsible owner. Close with the exact tested combinations and any unresolved path. The deliverable is a coherent reconstructed object and an explainable recovery decision, not merely a transfer that eventually stops moving.

Make the reasoning concrete.

A fictional publisher updates the middle chapter of a large public reference pack while a synthetic client retains its opening portion. The final file has the expected name and opens, but the team has not compared it with either intact edition.

The publisher accepts only a demonstrated coherent edition and records the restart behavior separately. No production download or protected file is touched.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Identity

   Which intact approved object defines the comparison?

2. Retained part

   What material exists at interruption?

3. Response

   What does the supplied continuation actually return?

4. Reconstruction

   Does the final object match a single approved edition?

5. Recovery

   What happens when retained progress cannot be trusted?

Watch for the wrong conclusion.

• Testing only a clean full download.
• Equating an openable file with a coherent edition.
• Hiding uncertain reconstruction behind a successful progress indicator.

Sources & scope

Acceptance workflows and fictional examples are editorial analysis. Technical statements and their applications remain source-derived even when embedded in original scenarios. Results apply only to the tested environment. No real clipboard access, sharing, permission changes or production operations are performed.

• MDN: HTTP range requests →Primary technical documentation · Supports: Supports partial intervals and conditional full replacement; not universal download-client behavior.