Cloudflare Origin Range Requests replace range-size tuning with fixed cache chunks

Cloudflare rebuilds range caching

Cloudflare has launched Origin Range Requests, a self-service cache feature available on all plans that changes how its edge satisfies HTTP range requests. Instead of requiring a tuned range size per zone, Cloudflare now fetches origin data in ranges aligned to the fixed-size chunks its Pingora-based cache already uses for storage. According to the Cloudflare blog, enabling it takes a single Cache Rule, with no size to configure and no support ticket. The company reports that on R2, its object storage service, p99 time to first byte dropped by roughly half, and a follow-up change cut tiered cache traffic for R2-like workloads by about 6%.

Why the old range caching wasted bandwidth

A range request asks for part of a resource: the client sends a normal GET with a Range header, and a supporting server replies 206 Partial Content with a Content-Range header identifying the returned bytes. Video players use them to seek, download managers to resume interrupted transfers, package managers to fetch part of an artifact.

Cloudflare's earlier implementation, which the company likens to the cache-slicing approach described in an nginx blog post, mapped every client request onto fixed-size ranges of a file, with the range size and applicable file extensions configured per zone. That size created a tradeoff: small ranges meant many small origin pulls plus memory pressure from coalescing requests in memory, while large ranges made Cloudflare download far more than the client wanted. A request for a few megabytes could trigger a 128 MiB origin pull that then moved between data centers, sometimes after the viewer had already left. Because the size was part of the cache key, changing it also invalidated cache entries.

Concurrency suffered too. Requests landing inside the same configured range could block one another no matter how far apart they sat, and the nginx-based cache could not combine range caching with concurrent streaming, so each range had to finish downloading before anyone could read it. Waste multiplied at every hop: origin to data center, between cache tiers, then to the client. In production, Cloudflare says, configured sizes ranged from tens of kilobytes to tens of gigabytes.

Fixed chunks replace the setting

The fix came from Pingora, the proxy Cloudflare built to replace nginx in its caching tier. Pingora already stores every cached file on disk in fixed-size chunks so that interrupted downloads can resume; Origin Range Requests simply makes that chunk the unit of fetching. The edge serves any requested bytes that are already cached, pulls missing bytes from the origin using ranges aligned to chunk boundaries, stores them in the same chunks used for ordinary caching, and returns only what the client asked for. A request for bytes 150–250 may fetch the entire chunk containing them, but the response still carries exactly bytes 150–250.

Over-fetching is not gone: a request smaller than a chunk can still pull the whole chunk. The difference, Cloudflare argues, is that the overhead now has a fixed ceiling instead of depending on a customer-selected size with unpredictable effects on the CDN and the origin.

Coordinating cached, in-flight and fetched bytes

The genuinely hard part, per Cloudflare, is producing one correct response when the requested bytes are spread across cached data on disk, a download already in flight, and a fresh origin fetch. The edge reads metadata describing which ranges are complete, serves what it can, fetches aligned ranges for the rest, records what was written, and composes the final response with accurate Content-Range and Content-Length headers. One request can combine a cached prefix, an attached in-flight download and a newly fetched suffix, and a second request whose bytes are covered by an ongoing download can attach to it rather than trigger another origin fetch.

Composition is permitted only when all bytes come from the same representation. Cloudflare verifies that each origin subresponse matches the requested range, that the asset's total size stays stable, and that the entity tag is consistent across subrequests. If-Range mismatches return the full representation, and content about to be decompressed is served whole, because byte offsets over compressed data differ from those of the decompressed body. Satisfiable ranges receive 206, unsatisfiable ones 416 Range Not Satisfiable.

Before the general launch, Cloudflare migrated existing users of the old feature, starting with the heaviest cases: large volumes of concurrent range requests against very large files under spiky traffic.

Why it matters

Range requests are how large files get delivered, and the old model charged origins and cache tiers for bytes no client ever consumed. Bounding over-fetch at the chunk level makes partial-content delivery efficient across access patterns — a small seek, a sequential download and a multi-gigabyte media file no longer need different settings. For anyone serving large files through Cloudflare, the feature removes a configuration problem that previously required understanding the CDN's internals, and the R2 numbers suggest the latency and bandwidth savings are substantial at scale.