Origin Range Requests: Serving large files without range-request tuning

Introduction and Key Takeaways

Cloudflare announced the general availability of Origin Range Requests, a self-service feature on all plans that handles range requests for large files without requiring users to tune range sizes or contact support. Powered by Cloudflare's Pingora-based caching server, the new implementation eliminates the static zone configurations of the past. For Cloudflare R2 object storage, the p99 time to first byte dropped by about half, and follow-up improvements cut tiered cache traffic for R2 and similar workloads by approximately 6%.

Understanding Range Requests and Past Limitations

An HTTP range request allows a client to ask for a specific part of a resource rather than the whole file using a Range header, returning a 206 Partial Content status. These requests are common for video streaming, resume-capable downloads, package managers, and file inspections. Previously, Cloudflare used a static zone configuration resembling cache-slicing via nginx, mapping client requests to fixed-size ranges configured per zone. This created severe tradeoffs: small ranges caused excessive origin requests and memory pressure, while large ranges forced Cloudflare to download far more data than requested. Furthermore, concurrent requests could block each other, and the old cache could not combine range caching with concurrent streaming.

The New Pingora-Based Chunk Architecture

Transitioning from nginx to a Pingora-based caching server resolved these architectural hurdles. Pingora stores every cached file on disk in fixed-size chunks, eliminating the need for a customer-selected range size setting. When a range request arrives, Cloudflare serves cached bytes directly and fetches missing bytes aligned to the cache's fixed-size chunk boundaries. While small or non-aligned requests still incur extra work, this overhead is bounded, predictable, and independent of custom range configurations.

Coordinating Cached and In-Flight Data

Handling range requests requires a sophisticated coordinator rather than a simple cache lookup. The system looks up asset headers and range-coverage metadata, reads available parts from disk or memory, fetches missing coverage from the origin using aligned ranges, writes new bytes to metadata, and combines the pieces with correct Content-Range and Content-Length headers. If an existing download covers another request's bytes, subsequent requests can attach to that active download, preventing redundant origin fetches. The coordinator also validates entity tags, representation stability, and If-Range headers to ensure data integrity, avoiding range combination for compressed assets about to be decompressed.

Performance Impact and Availability

Before general release, Cloudflare migrated existing users starting with spiky, high-concurrency workloads. For Cloudflare R2, where the old range size was 64 MiB, the transition dropped p99 time to first byte by roughly half on both cache hits and misses. Additionally, tiered cache traffic for R2 and similar workloads fell by about 6% week over week. Origin Range Requests is available today across all plans and can be enabled simply by creating a Cache Rule and setting Origin Range Requests to On, or via the API.