Cloudflare has overhauled how its CDN caches HTTP range requests, the mechanism that lets browsers, video players, and download managers fetch just part of a large file instead of the whole thing. The result, called Origin Range Requests, is now available as a self-service Cache Rule on all plans, with no range size to configure and no need to contact support.
Range requests let a client ask a server for specific byte ranges of a file using the Range header, with the server replying 206 Partial Content and a Content-Range value. This is how video players seek to a timestamp, download managers resume interrupted transfers, and package managers pull partial artifacts without downloading an entire file.
The problem with fixed range sizes
Cloudflare’s previous caching approach, built on nginx, mapped each request to fixed-size ranges configured per zone, similar to nginx’s own cache-slicing approach. That created an unavoidable tradeoff: small ranges meant many small origin requests and memory pressure from coalescing them, while large ranges meant Cloudflare pulled far more data from the origin than a client actually asked for. Changing the range size also invalidated existing cache entries, since the size was baked into the cache key.
The old system had other costs too. Concurrent requests landing in the same range could block each other regardless of how far apart the actual requested bytes were. It also couldn’t be combined with Cloudflare’s concurrent streaming feature, which allows multiple clients to read a file from cache while it is still being written, so combining both features cut responses short and forced extra origin fetches for popular files.
Fixed-size chunks instead of configurable ranges
The fix emerged from Cloudflare’s shift to a Pingora-based caching server, which already stores cached files on disk in fixed-size chunks to make resuming interrupted downloads easier. Rather than exposing a tunable range size, Cloudflare now simply uses the existing chunk size as the unit for range caching. For any range request, the system checks which bytes are already cached, serves those directly, and fetches only the missing bytes from the origin in chunk-aligned ranges. The client still receives only the bytes it requested in the response.
This does not eliminate extra work entirely. A request smaller than the chunk size can still trigger a fetch of the whole chunk, and non-aligned ranges require some additional effort. But that overhead is now bounded and predictable, rather than driven by a customer-chosen setting that could produce unpredictable load on Cloudflare and origin servers.
Internally, satisfying a single range request can now involve stitching together a cached prefix, an in-flight download, and a newly fetched suffix, while still returning one coherent response with accurate Content-Range and Content-Length headers.
Measured impact
Cloudflare reports that for R2, its object storage product, the new approach cut p99 time to first byte by about half. A follow-up improvement reduced tiered cache traffic for R2 and similar workloads by roughly 6%.
Why it matters for site owners
For hosting providers and site operators serving large files such as video, software downloads, or backups through Cloudflare, this change removes a configuration burden that previously required understanding internal caching behavior to avoid wasted bandwidth and inconsistent performance. Enabling Origin Range Requests via a Cache Rule should make large-file delivery more efficient without manual tuning.