Cloudflare has introduced a major overhaul to how its content delivery network handles HTTP range requests, rolling out a self-service feature designed to eliminate widespread bandwidth waste and disk operation inefficiencies associated with serving large files. The new capability, dubbed Origin Range Requests, is now available across all Cloudflare plans, promising significantly faster load times for video streams, large software updates, and heavy media assets without requiring complex configuration or manual tuning from network administrators.
The announcement addresses a long-standing architectural challenge in the CDN industry. When a modern video player seeks to the middle of a media file, it typically issues an HTTP range request asking for only a few megabytes of data around the desired timestamp. Under legacy range caching architectures, satisfying that single narrow request could force a CDN to pull vast amounts of data from the origin server—sometimes as much as 128 megabytes—and shuttle those unnecessary bytes across multiple global data centers. In many cases, this resource-heavy movement continued even after the viewer had already closed the video player or navigated away from the page.
At internet scale, naive handling of range requests leads to massive inefficiencies, consuming unnecessary network bandwidth and driving up disk input/output operations. To solve this, Cloudflare completely rebuilt how its edge cache processes partial file requests, moving away from older legacy systems tied to rigid, zone-specific configurations. The performance gains from the new infrastructure have already been proven internally. For Cloudflare’s R2 object storage, the 99th percentile time to first byte dropped by roughly half, while a subsequent optimization cut tiered cache traffic for R2 and similar workloads by approximately 6 percent.
The mechanics of partial content delivery rely on standard web protocols. An HTTP range request allows a client to ask for a specific segment of a resource rather than downloading the entire file from the beginning. The client sends a standard GET request accompanied by a Range header specifying the exact byte offsets it requires. If the server is properly configured to support these partial requests, it responds with a 206 Partial Content status code along with a Content-Range header identifying the returned byte range and the total file size.
These requests are ubiquitous across modern web applications. Video players utilize them to jump directly to seek positions in media files without buffering whole movies. Download managers rely on them to resume interrupted file transfers seamlessly, while software package managers fetch isolated parts of large distribution artifacts. Similarly, client applications frequently use range requests to inspect the metadata or tail end of a massive file without downloading everything that precedes it. While clients have always retained full control over whether to issue a range request, Cloudflare’s newly deployed architecture fundamentally changes how the edge network satisfies those demands.
Historically, Cloudflare supported range caching through static zone configurations, an approach that mirrored the cache-slicing mechanisms commonly found in traditional proxy servers like NGINX. In this legacy model, each incoming client request was mapped to fixed-size file ranges, with the specific range size and targeted file extensions configured manually per zone. This created an unavoidable engineering trade-off. Setting a small range size resulted in a high volume of fragmented origin requests and created severe memory pressure on Cloudflare’s internal systems as they attempted to coalesce numerous small requests in memory. Conversely, setting a large range size forced the network to download far more data than the client actually needed. Furthermore, modifying the range size configuration invalidated existing cache entries because the size parameter formed part of the underlying cache key.
This legacy design also created frustrating bottlenecks for end users. Concurrent requests falling within the same file range could block one another, regardless of how far apart the actual requested byte offsets were. Additionally, the older NGINX-based caching architecture could not combine range caching with concurrent streaming, a feature Cloudflare developed to allow multiple clients to read a file from the cache while it was still actively being written. Enabling both features simultaneously caused responses to be cut short, requiring every range to be fully downloaded before anyone could read it, and forcing popular files to trigger separate origin fetches for every single range.
The resulting waste was multiplied across every hop of Cloudflare’s distributed edge infrastructure, moving from the origin server to an initial data center, traversing cache tiers, and finally heading out toward the client. Because no single static range size could ever accommodate a small video seek, a sequential file download, a massive media asset, and every possible origin topology, these internal limitations frequently bubbled up to affect customers.
The opportunity to resolve these architectural limitations arrived alongside Cloudflare’s transition from NGINX to Pingora, its custom-built, memory-safe asynchronous proxy server that connects the network to the internet. Because Pingora was already designed to store every cached file on disk in fixed-size chunks to facilitate seamless download resumption, engineers realized that the cache range size no longer needed to be a manual setting at all. Instead, the range size could simply match the natural chunk size of the underlying storage engine.
Under the new implementation, when a range request arrives, Cloudflare checks which of the requested bytes are already present in the local cache and serves them directly. For any missing bytes, the edge fetches origin ranges that are perfectly aligned to the cache’s fixed-size chunk boundaries, stores the resulting data in the same chunks used for standard cache storage, and ultimately returns only the precise bytes requested by the downstream client. For example, a request for a narrow byte range can prompt Cloudflare to fetch the aligned chunk containing those bytes, while the downstream response delivered to the client contains strictly the requested subset of data.
While this approach does not completely eliminate extra work for requests smaller than the standard chunk size—such requests can still require fetching the entire enclosing chunk—the resulting overhead is strictly bounded, predictable, and decoupled from customer-configured settings that previously caused unpredictable spikes in origin traffic.
Parsing an incoming Range header is a straightforward programming task, but producing a single, correct HTTP response when the requested bytes are split across pre-cached data, an active origin response, and downloads already in progress presented a significant engineering hurdle. The modern edge cache functions as a sophisticated coordinator rather than performing a simple, isolated cache lookup. A single client request can now leverage a cached data prefix, attach to an ongoing in-flight download, and fetch a newly required suffix simultaneously. Although the internal origin response may be larger than the downstream response delivered to the browser, the final status codes and headers accurately describe only the requested range.
If an existing download happens to cover the bytes needed by a subsequent request, that second request can piggyback directly onto the active download instead of triggering an independent origin fetch, effectively sharing the workload during traffic surges for popular large assets. The underlying design relies on existing cache data models, where headers identify asset versions, file bodies are stored in bounded chunks, and metadata records precisely which byte ranges have been written successfully.
To maintain strict protocol compliance, composed range responses are verified to ensure all bytes belong to an identical representation. The edge coordinator validates that each origin response matches the requested range, that the total asset size remains stable, and that entity tags remain consistent across subrequests. Utilizing the If-Range header, clients can request a range conditionally, ensuring that if the resource has been modified, Cloudflare returns the full representation rather than stitching together mismatched bytes from different versions. Furthermore, Cloudflare avoids composing ranges for assets that are undergoing real-time transformations like decompression, ensuring that transformed full responses are served safely when range boundaries cannot be reliably mapped.
Before opening the feature to the general public, Cloudflare migrated existing users of its legacy range-caching system onto the new implementation, prioritizing workloads that experienced the most severe operational strain. These heavy workloads typically involved massive files subject to heavy concurrent range requests and highly volatile traffic patterns. Under the old system, configured range sizes ranged wildly from tens of kilobytes to tens of gigabytes, leading to severe resource amplification where minor read requests triggered gigabyte-scale data transfers across multiple data centers.
Cloudflare’s R2 object storage service served as the largest internal testbed for the new architecture. Previously configured with a 64-megabyte range size, small read operations crossing a boundary could easily force 128 megabytes of internal data transfer. Following the transition to the new chunk-aligned coordination system, these resource-intensive friction points were largely eliminated, stabilizing internal transfer volumes and improving response latency across the board.
Getting started with Origin Range Requests requires minimal effort now that the cache no longer relies on manual range-size tuning. Network administrators can activate the feature simply by identifying matching traffic through Cloudflare’s Cache Rules interface, leaving the edge network to handle the complex underlying chunking and cache coordination automatically.
The feature is specifically tailored for traffic profiles where clients naturally request partial segments of large, cacheable objects, such as media streaming platforms, software distribution networks, and large document repositories. Cloudflare plans to make this chunk-aligned coordination the default method for serving specific file types across its global network. The capability does not alter standard cache eligibility rules, meaning an uncacheable response will not become cacheable simply by turning the feature on, and origin servers must still support standard byte ranges for partial fetches to succeed. Customers can enable the setting directly through the dashboard under Caching and Cache Rules, or programmatically via the API by setting the origin range requests mode to active, allowing edge servers to seamlessly manage cache coordination and protocol correctness.
