Summary: On 2026-10-23, Cloudflare shipped Origin Range Requests, a self-service feature on all plans that changes how its edge cache handles HTTP range requests. Instead of a per-zone range-size setting, it fetches origin ranges aligned to fixed-size cache chunks. For R2, the biggest internal user, p99 time to first byte roughly halved and tiered cache traffic dropped about 6%.
Why the old range caching hurt
Range requests are how big files get delivered: a video player seeks to the middle of a movie, a download manager resumes an interrupted transfer, a package manager grabs part of an artifact. Cloudflare’s previous implementation — similar to the cache-slicing described in an nginx blog post — mapped every client request to fixed-size ranges whose size and file extensions were configured per zone.
That size was a bad tradeoff no matter what you picked. Small ranges meant many tiny origin requests and memory pressure from coalescing them. Large ranges meant a request for a few megabytes could pull 128 MiB from the origin — sometimes a request that wouldn’t fill a floppy disk triggered a few DVDs’ worth of transfer across several data centers, after the viewer had already left. Worse, changing the range size invalidated cache entries, and concurrent requests landing in the same range could block each other. Cloudflare says both patterns caused real operational incidents.
The fix: the chunk is the range
The company’s move from nginx to a Pingora-based caching server opened the door. Pingora already stores every cached file on disk in fixed-size chunks to support resumable downloads. The insight: if the cache already thinks in chunks, the range size doesn’t need to be a setting — it can just be the chunk.
Now the edge checks which requested bytes are cached, serves those directly, and fetches only the missing bytes in origin requests aligned to chunk boundaries. A request for bytes 150-250 may fetch a whole aligned chunk internally, but the client still gets exactly 150-250. The extra work is bounded and predictable rather than set by a customer-selected knob.
Serving one correct response is the harder part — requested bytes can span cached data, in-flight downloads, and fresh origin fetches. The edge acts as a coordinator: it reads range-coverage metadata, pulls missing coverage from the origin, records completed ranges, and assembles the response with accurate Content-Range and Content-Length. A second request whose bytes are already being downloaded attaches to that download instead of starting another origin fetch, which shares work during traffic bursts.
Correctness checks matter here too. Each origin response must match the requested range, the total asset size must stay stable, and entity tags must remain consistent across subrequests. If If-Range doesn’t match, Cloudflare returns the full representation rather than stitching bytes from different versions — standard 206, 416, or full-response behavior.
What the numbers showed
Before the general rollout, Cloudflare migrated existing users of the old range-caching feature, starting with the heaviest workloads. R2, its object storage, had a configured range size of 64 MiB, so a small read crossing a boundary could cost 128 MiB of inter-data-center transfer. After moving to the new implementation:
- p99 time to first byte dropped by roughly half across R2’s storage regions, on both hits and misses.
- A coordinator change that combines on-disk bytes with upstream bytes in one response cut tiered cache traffic for R2-like workloads about 6% week over week — petabytes less movement between data centers daily.
How to turn it on, and where it fits
Configuration is a Cache Rule: match your large-file traffic and set Origin Range Requests to On, via the dashboard under Caching > Cache Rules or the API with origin_range_requests: { "mode": "on" }. No range size to tune, no support ticket.
The intended workloads are the ones where clients naturally request slices of a large cacheable object: seekable MP4 video, resumable downloads, package repositories, disk images, and — notable for this blog’s readers — AI workloads transferring large model files or fetching selected regions of model artifacts.
Two limits to keep in mind. Enabling the feature doesn’t make an otherwise uncacheable response cacheable, and your origin must support byte ranges for partial fetches to help at all. The design also echoes a theme I’ve covered before: pushing variation-handling into the cache layer with explicit rules, as with Cloudflare’s Vary support — the goal is that customers choose which traffic to match, and the edge handles the cache mechanics.
Cloudflare says it plans to make this the default way certain file types are served, adjustable by cache rules. If you serve large files today, the practical next step is identifying that traffic pattern and enabling the rule — then watching your origin egress, since that’s where the waste used to land.
Sources
View the original post on X