Cloudflare has announced the general availability of Origin Range Requests, a newly engineered caching feature designed to solve long-standing inefficiencies associated with delivering large files over content delivery networks. Available today as a self-service feature across all plans, the implementation eliminates the need for manual range-size tuning or contacting customer support, allowing users to enable it seamlessly through a standard Cache Rule.
The release follows a complete overhaul of how Cloudflare’s edge network handles HTTP range requests, a core mechanism used across the web for streaming media, resuming interrupted downloads, and fetching specific segments of large software packages or archives. Under legacy caching architectures, handling these partial requests frequently resulted in wasted network bandwidth, excessive disk operations, and internal operational bottlenecks that occasionally impacted customer experience.
To understand the scope of the problem, it helps to examine how HTTP range requests function fundamentally. An HTTP range request asks a server for a specific portion of a resource rather than downloading the entire file from start to finish. A client sends a standard GET request accompanied by a Range header specifying the exact byte offset it requires. If the origin server supports this capability, it responds with a status code of 206 Partial Content along with a Content-Range header identifying the exact bytes being returned.
This approach is ubiquitous in modern web architecture. A video player seeking to the middle of a movie requests only the bytes surrounding that seek position rather than pulling gigabytes of unneeded video data. A download manager relies on ranges to resume an interrupted file transfer without restarting from zero. Package managers and scientific data processors fetch discrete chunks of massive artifacts for inspection or verification. However, while clients dictate whether to request a range, the burden of fulfilling that request efficiently falls squarely on the CDN.
For years, Cloudflare—like many other infrastructure providers—relied on a static zone configuration for range-request caching. This legacy implementation mapped each incoming client request to fixed-size ranges of a file, with the specific range size and targeted file extensions configured manually per zone. This design mirrored traditional cache-slicing methods utilized by proxy software such as NGINX.
The fundamental flaw in this legacy approach lay in an unavoidable architectural tradeoff. Configuring small ranges meant that a single client interaction could trigger a cascade of numerous small origin requests, placing heavy memory pressure on Cloudflare’s infrastructure as the system attempted to coalesce all those individual requests in-memory. Conversely, configuring large ranges forced Cloudflare to download significantly more data from the origin server than the client actually requested. Furthermore, updating the configured range size dynamically invalidated existing cache entries because the size parameter was baked directly into the cache key.
This rigid design created secondary complications for end users. Concurrent requests falling within the same configured range—regardless of how far apart the individual clients’ requested byte ranges actually were—could block one another. Additionally, the legacy NGINX-based cache could not combine range caching with concurrent streaming, a feature engineered to allow multiple clients to read a file from the cache while it was still actively being written. Turning both features on simultaneously cut responses short, meaning each range had to be fully downloaded before any user could read it, forcing popular files to trigger a separate origin fetch for every individual range.
The resulting waste was multiplicative. Extra bytes crossed multiple tiers of Cloudflare’s distributed cache architecture: traveling from the origin server to an initial data center, moving between cache tiers, and finally pushing toward the client. Because no single static range size could ever perform optimally across small seeks, sequential downloads, massive media files, and varied origin topologies, internal caching limitations were frequently exposed to customers who simply wanted their large files served efficiently without needing a deep background in edge networking.
The path toward a permanent solution opened as Cloudflare transitioned its edge infrastructure from NGINX to Pingora, a custom memory-safe proxy built in-house to connect Cloudflare to the internet.
A Request for Part of a File
Within the new Pingora-based architecture, engineers discovered an elegant solution rooted in how the proxy already operated. To facilitate the seamless resumption of interrupted downloads, Pingora natively stores every cached file on disk in fixed-size chunks. Because the caching layer already conceptualized data storage in fixed chunks, the range size no longer needed to be a manual setting configured by the user. Instead, the native cache chunk size itself could serve as the foundational unit for range requests.
Under the new Origin Range Requests implementation, when a client submits a range request, Cloudflare first checks which of the requested bytes already exist within its local cache, serving those matching bytes directly. For any missing bytes, the system fetches origin ranges that are strictly aligned to the cache’s fixed-size chunk boundaries. These fetched bytes are then stored in the exact same chunks used for ordinary cache storage, while the edge returns only the precise bytes originally requested by the client.
For example, if a client requests bytes 150 through 250, Cloudflare may fetch the aligned chunk containing those specific bytes from the origin. However, the downstream response delivered to the client still contains exclusively bytes 150 through 250. While this does not entirely eliminate extra data transfer for requests smaller than the established chunk size—such a request may still require fetching the entire enclosing chunk—the critical difference is that the extra work is now strictly bounded, predictable, and entirely divorced from a customer-selected configuration parameter that could previously trigger unpredictable downstream effects.
Coordinating Cached and In-Flight Data
While parsing an incoming HTTP Range header is mathematically straightforward, producing a single, correct HTTP response when requested bytes are fragmented across a combination of locally cached data, a fresh origin response, and downloads already in progress presented a significant systems engineering challenge.
The modern edge architecture acts as a sophisticated coordinator rather than performing a simple, isolated cache lookup. A single downstream request can seamlessly stitch together a cached file prefix, an active in-flight download, and a newly fetched file suffix. Although the internal origin response may technically be larger than the downstream response to accommodate chunk alignment, the final status codes and headers sent to the client describe solely the requested range.
Furthermore, if an existing download is already in progress that covers another concurrent request’s required bytes, a second incoming request can attach directly to that active download instead of initiating an entirely separate origin fetch. This mechanism shares the computational and networking load efficiently during traffic spikes for popular large media assets or software releases. The entire design relies cleanly on Cloudflare’s existing data model, where headers identify the asset version, file bodies are stored in bounded chunks, and metadata accurately records which specific ranges have been written successfully.
Composed range responses, however, are only legally valid when all constituent bytes belong to the exact same file representation. To ensure strict consistency, the edge coordinator validates that every origin response matches the requested range precisely, that the total asset size remains stable, and that the entity tag, or ETag, remains consistent across all subrequests.
The standard HTTP If-Range header plays a vital role in this process, allowing a client to request a range conditionally only if the resource representation still matches a known validator. If the validator fails to match, Cloudflare bypasses composition entirely and returns the full representation rather than dangerously combining bytes from different file versions. Similarly, Cloudflare avoids composing ranges for any representation it is about to transform or decompress, as applying a byte range over compressed data yields entirely different results than applying it to a decompressed response. In such edge cases, the network transparently serves the transformed full response rather than advertising a range it cannot honor correctly.
What Changed in Production
Before opening Origin Range Requests to the broader public, Cloudflare migrated its existing users of the legacy range-caching feature onto the new Pingora-backed implementation, prioritizing workloads that previously experienced the highest operational friction.
These high-impact workloads characteristically involved heavy bursts of concurrent range requests against massive files under spiky traffic patterns. Under the old system, configured range sizes spanned wildly from tens of kilobytes to tens of gigabytes. Large range settings meant that a minor read request could force the network to pull massive volumes of data from the origin and shuttle it across multiple international data centers—frequently long after the client had already abandoned the request. Conversely, small range settings transformed a single client request into a long queue of tiny origin requests, each tying up system memory while waiting for completion. Both failure modes had historically triggered real operational incidents.
Cloudflare’s R2 object storage service served as the largest internal testbed for the new architecture. Previously configured with a 64 MiB range size, a small read crossing a range boundary on R2 could inadvertently force the network to transfer 128 MiB between data centers. Following R2’s migration to the new implementation, internal metrics showed dramatic improvements, including a reduction of the p99 time to first byte by approximately half, alongside a subsequent optimization that cut tiered cache traffic for R2 and similar heavy workloads by roughly 6%.
Getting Started
With the caching layer no longer dependent on manual, customer-selected range sizes, configuration has been streamlined. Customers simply select matching traffic streams through standard Cache Rules, leaving the edge network to manage chunking, alignment, and cache coordination automatically.
The feature is specifically tailored for traffic profiles where clients naturally request discrete portions of large, cacheable objects, such as video streaming platforms, software update distributions, large archive repositories, and podcast networks. Enabling the feature does not alter standard cache eligibility rules; an otherwise uncacheable response will not become cacheable simply by turning on Origin Range Requests, and the origin server must natively support byte ranges for partial origin fetches to succeed.
To activate the feature, administrators can create a Cache Rule matching their large-file traffic patterns and toggle Origin Range Requests to the "On" position directly within the dashboard under Caching and Cache Rules, or programmatically via the API. By shifting the complexity of cache coordination to the edge, Cloudflare aims to provide efficient, reliable content delivery out of the box for high-bandwidth workloads across the web.
