Cloudflare Launches Origin Range Requests for Large Files
Cloudflare has rebuilt its cache architecture to automatically coordinate partial fetches, aiming to eliminate the bandwidth waste associated with naive byte-range caching for large files.
Radwan AbdulhadiEditor and technology writer
Rebuilding Cache Architecture for Large Files
Large files such as video streams, software packages, and large archives are frequently delivered using HTTP range requests. When a video player skips to the middle of a movie, it requests only a few megabytes. Under older range caching methods, however, that single request could force Cloudflare to pull 128 MiB from the origin and move it between data centers, frequently long after the viewer had already abandoned the stream. Caching these requests naively has historically caused significant network bandwidth waste and heavy disk operations for content delivery networks operating at scale.
To address these operational hurdles, Cloudflare rebuilt how its cache handles partial data. Today, the company is introducing this new implementation as Origin Range Requests, deploying it as a self-service feature across all plan tiers. According to the company, users can enable the functionality directly through a Cache Rule without requiring manual range size tuning or direct support assistance.
Moving Past Static Zone Configurations
For years, Cloudflare supported range-request caching through static zone configurations that closely resembled traditional cache-slicing methods. In those legacy architectures, each client request mapped to fixed-size file ranges configured per zone. This created a persistent tradeoff: smaller ranges generated numerous origin requests and caused memory pressure from in-memory coalescing, while larger ranges forced the network to download substantially more data than clients actually requested.
Furthermore, updating the range size invalidated existing cache entries because the size formed part of the cache key. Concurrent requests falling within the same range could also block one another regardless of how far apart the requested ranges were. Additionally, the older nginx-based cache could not combine range caching with concurrent streaming without cutting responses short, requiring popular files to undergo a separate origin fetch for every individual range.
Leveraging Pingora for Chunk-Based Caching
The transition from nginx to a proxy server built on Pingora created an opportunity to eliminate these rigid configurations. Pingora already stored every cached file on disk in fixed-size chunks to simplify the resumption of interrupted downloads. Because the underlying cache architecture already thought in terms of chunks, the range size no longer needed to be a configurable setting.
Under the new system, when a client makes a range request, Cloudflare verifies which requested bytes are already cached and serves those portions directly. For missing bytes, the proxy fetches origin ranges aligned precisely with the fixed-size chunk boundaries of the cache. It stores the results in the standard cache storage chunks and returns strictly the bytes requested by the client downstream.
Coordinating Complex Partial Fetches
Parsing incoming Range headers is straightforward, but generating a correct single response when requested bytes span cached data, live origin responses, and active downloads requires advanced coordination. The system functions as a coordinator rather than a simple cache lookup, capable of combining a cached prefix, an in-flight download, and a newly fetched suffix into a unified response.
When an ongoing download covers the bytes needed by another request, the second request attaches to the existing download rather than initiating a separate origin fetch. This mechanism shares computational and network work during traffic bursts for popular large assets, maintaining stability across distributed caching layers.
Performance Gains for Object Storage
By automating the coordination of partial fetches without manual range tuning, Cloudflare achieved notable performance gains. For R2, the company's object storage service, the p99 time to first byte dropped by approximately half. A subsequent optimization further reduced tiered cache traffic for R2 and comparable workloads by roughly six percent.
The design ensures that any extra work from non-aligned ranges remains bounded and predictable, removing customer-selected configurations that previously caused unexpected behaviors across origin servers and caching infrastructure.
Sources
- Cloudflare BlogOrigin Range Requests: Serving large files without range-request tuning
Continue chronologically
Related entity coverage
Related stories
Cloudflare Reclaims 100TB of RAM With Math and Rust
Cloudflare says a statistical redesign of consistent hashing cut more than 100TB of RAM from a Pingora-based service across its global network.
Cloudflare Launches K2 Public Beta for Serverless Event Streams
Cloudflare has introduced K2 in public beta, a serverless event streaming service built on R2 object storage for high-scale data and long retention.
Tracking Exploitation and Patching of eMudhra’s Weak Keys
An in-depth look at how Cloudflare tracked exploitation attempts, analyzed source code using AI, and patched eMudhra's unprecedentedly weak certificate keys.
Cloudflare AI Search Launches Into General Availability
Cloudflare's AI Search reaches general availability, introducing native image embeddings, PDF OCR, larger file limits, and new billing terms.
