Serving range requests for resumable downloads

Goal

Let clients resume interrupted transfers of large files and fetch parts of them without downloading everything, in a way intermediaries understand.

Prerequisites

Files served as stable representations with a strong ETag and Last-Modified, and no on-the-fly Content-Encoding: byte ranges apply to the encoded representation, so a response compressed per request has no stable offsets. Range support is optional, so every client must cope with a full 200 instead.

Steps

1. Send Accept-Ranges: bytes and a strong ETag on full responses for downloadable resources; the header invites clients to try ranges.
2. Honour Range only on GET, the only method with defined range handling. Ignore unknown range units. RFC 9110 permits ignoring or rejecting invalid specifiers, overlapping ranges or many small unordered ranges as a denial-of-service defence.
3. Evaluate preconditions first: a conditional GET that yields 304 ignores Range. Then evaluate If-Range: an entity tag must match with strong comparison (clients MUST NOT send weak tags there), an HTTP-date must equal Last-Modified exactly; if the condition fails, ignore Range and send the full 200.
4. For one satisfiable range, respond 206 Partial Content with Content-Range: bytes 500-999/1234, a Content-Length equal to the part, and the same ETag, Content-Type, Last-Modified and Cache-Control as the full response.
5. For several ranges, build a multipart/byteranges body with a Content-Range per part; RFC 9110 lets a server coalesce overlapping or nearly adjacent ranges and send only a subset of what was requested.
6. When no range is satisfiable, for example a first position beyond the length, respond 416 Range Not Satisfiable with Content-Range: bytes */1234. A suffix range longer than the file (bytes=-500 on 300 bytes) yields the whole representation.
7. Client side: keep the ETag from the first response; to resume, send Range: bytes=<received>- with If-Range: "<etag>"; on 206 check that the first position in Content-Range equals the local offset before appending; on 200 discard the partial file and restart.
8. Test with curl -r 0-99 -D - URL, a resume (curl -C - -O URL), a request after replacing the file, and bytes=0-0,-1 for multipart.

Expected result

Interrupted downloads continue at the byte offset; a file replaced between attempts is fetched again from the start instead of being spliced; caches that implement ranges answer a subrange from a stored copy, which RFC 9111 permits even from an incomplete one if the range lies wholly within it.

Limits and test basis

Generated or negotiated content needs a stable representation per variant. A 206 may come from an intermediary's cache; RFC 9111 forbids a cache from storing partial responses whose range unit it does not understand. Steps follow the cited specifications; no throughput or failure-rate figures are claimed.