Cloudflare has announced a major overhaul of how its edge network handles HTTP range requests, introducing a self-service feature designed to eliminate the network inefficiencies and disk operation bottlenecks that have historically plagued content delivery networks operating at scale. The new capability, dubbed Origin Range Requests, aims to solve long-standing challenges associated with delivering large files, such as videos, software updates, and large data archives, by replacing rigid, zone-configured range caching with a dynamic, chunk-based architecture built on top of the company’s Pingora proxy framework.
The redesign comes in response to the fundamental friction inherent in how large files are consumed on the modern web. When a video player skips to the middle of a movie, for example, it typically issues an HTTP range request asking for a specific, localized byte sequence rather than downloading the entire file. Under Cloudflare’s legacy range caching system—which relied on static zone configurations and mechanisms similar to traditional cache-slicing architectures found in web servers like NGINX—fulfilling such a request often triggered a cascade of inefficiencies.
In the older system, each client request was mapped to fixed-size ranges determined by file extensions and zone settings. This created a difficult optimization trade-off for operators. If the configured range size was too small, a single client request could fracture into a long queue of tiny origin requests, placing heavy memory pressure on the proxy as it attempted to coalesce numerous in-memory fragments. Conversely, if the range size was large, Cloudflare’s edge network would frequently be forced to download vastly more data from the origin server than the client actually requested, moving megabytes or even gigabytes of unnecessary data across internal data centers—sometimes long after the viewer had abandoned the stream and closed the browser window.
These legacy limitations frequently exposed internal infrastructural constraints directly to customers. Furthermore, the older architecture could not seamlessly combine range caching with concurrent streaming, a feature engineered to allow multiple clients to read a file from the cache while it is still actively being written. Enabling both features simultaneously often cut responses short, requiring every range to be fully downloaded before any client could read it, and forcing popular files to endure separate origin fetches for every single range.
The turning point for Cloudflare arrived during its migration from NGINX to Pingora, the modern, memory-safe proxy built in Rust that now connects Cloudflare’s infrastructure to the broader internet. Because Pingora natively stores every cached file on disk in fixed-size chunks to facilitate the smooth resumption of interrupted downloads, engineering teams realized that the cache range size no longer needed to be a configurable, customer-managed setting. Instead, the cache chunk itself could serve as the natural boundary for range management.
Under the newly deployed architecture, when an edge node receives a range request, it first inspects which requested bytes are already locally cached, serving those immediately. For any missing bytes, the system fetches origin ranges precisely aligned to the fixed-size chunk boundaries of the cache. The fetched data is stored using the same standard chunks utilized for ordinary file storage, while the downstream client receives strictly the precise byte range it originally asked for. While requests smaller than the chunk size or requests spanning non-aligned ranges still incur some degree of extra fetching, that operational overhead is now strictly bounded, predictable, and entirely divorced from arbitrary customer configurations.
Managing this efficiently required sophisticated coordination at the edge. Rather than performing a single isolated cache lookup, a modern edge request can dynamically synthesize a response by stitching together a cached data prefix, an active in-flight download from the origin, and a newly fetched suffix. If multiple concurrent clients request different sections of the same large file, the edge coordinator allows subsequent requests to attach dynamically to an active download in progress rather than triggering duplicate origin fetches, thereby absorbing traffic spikes for popular media assets.
Before opening the feature to all customers, Cloudflare transitioned its existing users—starting with its own internal workloads—onto the new implementation. The heaviest internal user of the legacy range-caching system was R2, Cloudflare’s object storage service. Operating under a legacy range size of 64 MiB, a small read that inadvertently crossed a range boundary could force the network to transfer 128 MiB between data centers. Following the migration to the new chunk-aligned architecture, Cloudflare observed a dramatic performance enhancement, noting that the p99 time to first byte for R2 dropped by approximately half, while a subsequent optimization successfully reduced tiered cache traffic for R2 and comparable workloads by roughly six percent.
With the new architecture fully operational, Cloudflare is making Origin Range Requests available as a self-service feature across all account tiers, requiring no manual range size tuning or intervention from support teams. Customers seeking to optimize their large-file traffic can enable the capability by configuring a Cache Rule in the Cloudflare dashboard under Caching and Cache Rules, or programmatically via the API by setting the origin range requests mode to on. While the feature does not alter standard cache eligibility rules—meaning an otherwise uncacheable asset will not become cacheable simply by turning the setting on—it provides a streamlined, highly efficient mechanism for handling segmented downloads, media streaming, and large-scale data delivery without exposing infrastructure complexities to the end user.
