HTTP Range Requests
HTTP range requests let a client fetch a byte range of a resource, so a video player seeks without re-downloading and a download resumes after a drop.
Definition
HTTP range requests are the mechanism where a client sends Range: bytes=0-1023 and the server returns 206 Partial Content with the requested byte range, so that large resources can be fetched in pieces — for seeking, resuming, or parallelizing — without transferring the whole representation.
Context and scope
Applied in video streaming, large file download, PDF preview, and any resource where the client needs a subset of the bytes.
Common misconceptions
- Range requests are just chunked transfer — chunked transfer streams the whole body in pieces; range requests fetch arbitrary subsets, which is different and requires server support
- A server that accepts GET accepts Range — Range is optional; a server may ignore the header and return 200 with the full body, and the client must handle that
Anti-patterns
- Assuming the server supports range and not handling a 200 full-body response, breaking the resume logic
- Issuing overlapping range requests without coordination, downloading the same bytes twice and wasting bandwidth
Related concepts
Authoritative source
https://datatracker.ietf.org/doc/html/rfc9110#range.requests
What it is
HTTP range requests are the mechanism where a client sends Range: bytes=0-1023 and the server returns 206 Partial Content with the requested byte range, so that large resources can be fetched in pieces — for seeking, resuming, or parallelizing — without transferring the whole representation. Applied in video streaming, large file download, PDF preview, and any resource where the client needs a subset of the bytes. The protocol’s semantics — safe versus unsafe, idempotent versus non-idempotent, cacheable versus non-cacheable — are contracts the client and intermediary rely on, and violating them breaks the web.
How it works
Headers carry the negotiation: content type, encoding, caching directives, and conditional request validators together let a client and server reach the cheapest correct response. Connection reuse eliminates handshake overhead; multiplexing removes head-of-line blocking; streaming avoids buffering the entire body. Each feature has a failure mode — keep-alive on a broken proxy, multiplexing with a misbehaving server — that must be detected and handled.
When to apply and pitfalls
Apply whenever a client and server communicate across a trust boundary the protocol already spans. The pitfall is treating HTTP as a transport and ignoring its semantics — POSTing a retrieval, marking a mutating request cacheable, or omitting the validator that would enable a 304. Intermediaries — CDNs, proxies — implement the standard literally, so semantic violations produce surprising behavior far from the origin.