Cloudflare has introduced a redesigned architecture for handling HTTP range requests across its global content delivery network, aiming to eliminate the widespread network bandwidth waste and disk operation inefficiencies historically associated with serving large files at scale. The new implementation, launched as a self-service feature called Origin Range Requests available across all plans, fundamentally changes how the edge network satisfies partial file requests from clients without requiring customers to manually tune range sizes or coordinate with technical support.
The release follows a successful internal migration that moved existing workloads off legacy zone configurations. According to Cloudflare, the updated caching mechanics have already yielded significant performance gains, including cutting the p99 time to first byte by about half for its R2 object storage service and reducing tiered cache traffic by roughly 6% for similar data-heavy workloads.
The problem stems from the fundamental nature of how large files, such as high-definition videos, software updates, and large digital archives, are delivered over the modern web. When a video player skips to the middle of a movie, it issues an HTTP range request for a specific slice of the file rather than downloading the entire asset. Under Cloudflare’s previous range caching mechanism—which relied on static zone configurations and an approach similar to traditional cache-slicing used in other proxy servers—each incoming client request was mapped to fixed-size ranges of a file.
This legacy design created an acute operational dilemma centered on range sizing. If administrators configured small ranges, the network would generate a high volume of small origin requests, placing heavy memory pressure on the CDN as it attempted to coalesce all concurrent requests in memory. Conversely, if large ranges were configured, Cloudflare was forced to download vastly more data from the origin server than the client actually requested.
In worst-case scenarios, a trivial client request for a few megabytes could trigger the network to pull massive amounts of data from the origin and shuttle it across multiple data centers—sometimes long after the viewer had already abandoned the stream and closed the browser tab. Furthermore, because these range sizes were baked directly into the cache key, any subsequent modifications to the range size would immediately invalidate existing cache entries, leading to sudden spikes in origin load.
The limitations of the old system also introduced severe concurrency bottlenecks. Concurrent requests falling within the same file range would block one another, regardless of how far apart the actual client-requested bytes were. Additionally, the legacy cache infrastructure could not effectively combine range caching with concurrent streaming, a feature designed to allow multiple clients to read a file from the cache while it was still actively being written. Turning both features on simultaneously forced responses to be cut short, requiring every single range to be fully downloaded before any client could read from it, and demanding separate origin fetches for popular files across every individual range.
Shifting From Nginx to Pingora for Fixed-Size Cache Chunks
The opportunity to resolve these deeply rooted architectural constraints emerged as Cloudflare transitioned its edge infrastructure away from nginx and toward Pingora, its custom-built, memory-safe asynchronous proxy written in Rust. Because Pingora was already designed to store every cached file on disk in standardized, fixed-size chunks to facilitate the seamless resumption of interrupted downloads, the engineering team realized that the range size no longer needed to be a configurable customer setting. Instead, the native cache chunk size itself could serve as the universal boundary.
Under the new Origin Range Requests architecture, when a client issues a range request, Cloudflare first inspects its local storage to determine which requested bytes are already cached and serves those portions directly. For any missing bytes, the edge network intelligently fetches origin ranges that are strictly aligned to the fixed-size boundaries of the internal cache chunks. The resulting data is stored in the exact same chunks used for ordinary, non-ranged cache storage, but the network carefully returns down the wire only the precise bytes originally requested by the client.
While this approach does not entirely eliminate additional overhead for requests smaller than the established chunk size—such a request may still necessitate fetching the entire containing chunk—the critical difference is that the extra work is now strictly bounded and predictable. It is no longer dictated by arbitrary, customer-selected range sizes that could trigger cascading inefficiencies across distributed data centers and origin servers.
Coordinating Cached, In-Flight, and Origin Data
While parsing standard HTTP Range headers is straightforward, producing a single, cohesive response when the requested bytes are fragmented across locally cached data, active origin responses, and downloads already in progress presented a formidable engineering challenge.
To solve this, Cloudflare implemented a sophisticated edge-level coordinator. Rather than executing a simple, single-lookup cache retrieval, a single client request can now dynamically stitch together a cached prefix, an ongoing in-flight download from the network, and a newly fetched suffix from the origin server. While the internal origin fetch may temporarily handle a larger block of data to align with chunk boundaries, the downstream status code and headers sent to the client describe solely the requested range.
This coordination layer also provides significant deduplication benefits. If an existing background download is already fetching bytes that satisfy another incoming request, the second request can piggyback directly onto the active download instead of initiating a redundant origin fetch. This collaborative mechanism efficiently absorbs traffic spikes for popular large-scale assets, preserving origin bandwidth and reducing internal network chatter.
Before any composition occurs, the coordinator enforces strict validation checks to ensure data integrity. Composed range responses are only treated as valid if every individual byte belongs to the exact same asset representation. The system verifies that each origin response matches the requested range, that the overall asset size remains stable, and that the entity tag (ETag) stays consistent across all subrequests.
The implementation fully respects standard HTTP semantics, including the If-Range header, which allows clients to condition their requests on a matching validator. If a validator mismatch occurs, Cloudflare safely falls back to returning the full representation rather than stitching together bytes from mismatched file versions. Furthermore, the system intentionally avoids composing ranges for representations that are pending compression transformations, as a range calculated over compressed bytes would misalign with the expected byte offsets of a decompressed response.
Production Impact and Operational Transition
Before opening the feature to the broader public, Cloudflare transitioned its existing users—starting with internal services experiencing the most severe traffic strain—onto the new cache implementation. The most acute pain points historically existed in workloads characterized by heavy concurrent range requests against massive files under highly spiky traffic patterns.
R2, Cloudflare’s distributed object storage service, stood out as the largest internal consumer of the legacy range-caching system. Previously configured with a range size of 64 megabytes, a minor read operation that happened to cross a boundary could force the network to transfer 128 megabytes between data centers. Following R2’s migration to the Pingora-backed chunk coordination architecture, the platform registered dramatic improvements, most notably a halving of the p99 time to first byte and a subsequent 6% reduction in global tiered cache traffic for equivalent workloads.
With the underlying dependency on customer-configured range sizes successfully eliminated, product configuration has been streamlined. The feature is intended primarily 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.
Enabling the capability does not alter standard cache eligibility rules, meaning an otherwise uncacheable response will not be cached simply by turning the feature on, and the origin server must still natively support byte ranges to accommodate partial fetches. Customers can activate Origin Range Requests directly through the Cloudflare dashboard under caching rules or via the API by setting the appropriate configuration flag, allowing edge servers to handle the complex underlying mechanics of chunking, coordination, and protocol compliance automatically.
