Every video seek, every resumed download, every smart preloader relies on the same primitive: Range, the header that asks for bytes 1000000 through 1999999 instead of the whole object. Simple for a server; genuinely interesting for a cache, and the interesting part is where production surprises live.
The protocol basics
A server advertising Accept-Ranges: bytes answers Range requests with 206 Partial Content and a Content-Range header naming the slice. Multiple ranges in one request are legal and almost universally avoided. If-Range makes resumption safe: it conditions the range on a validator, so a changed file yields a full 200 instead of stitching bytes from two different versions, which is the corruption bug every download manager learned to fear.
What caches actually do with ranges
Strategies differ meaningfully by CDN. Some fetch the entire object on first range request and serve all future slices from cache, ideal for popular media, expensive for sparse access to huge files. Others cache ranges as independent segments, or fetch in fixed-size chunks (slice-by-slice fill) so partial interest fills the cache incrementally. Vendors document these behaviors, buyers rarely read them, and the difference decides both your origin traffic pattern and whether a user’s seek hits edge or origin.
Why this matters commercially and not just correctly: adaptive streaming has largely moved seeking into segment granularity, but the download economy, game patches, ML models, OS updates, podcast apps, remains pure range territory, and the objects are enormous. A range-hostile configuration on a 40 GB game patch means every resumed download restarts origin transfer from byte zero, and at patch-day scale the difference between chunked cache fill and naive full refetch is measured in origin terabytes. The teams shipping the biggest files think about ranges the most, which is exactly backwards from how the attention is usually distributed.
Failure modes worth knowing
Origins that ignore Range and return 200 with full bodies silently defeat resumption and can multiply egress dramatically under seek-heavy players. Compression interacts poorly: ranges apply to the encoded byte stream, so on-the-fly gzip of range responses is a recipe for mismatched slices; large media should be stored uncompressed or pre-compressed. And object updates without validator changes plus range caching equals stitched corruption, the bug that If-Range exists to prevent.
In practice
Verify the chain end to end: confirm 206 behavior from origin directly, then through the CDN, then check your provider’s range-fill strategy against your access pattern, full-fill for hot catalogs, chunked fill for long-tail archives. Instrument the ratio of 206 to 200 on media paths; a sudden shift is an early-warning signal that some layer stopped honoring ranges, usually right after somebody’s well-meaning config change.
Shipping large objects? The delivery review includes range-behavior verification across every layer you run.