CLOUDFLARE has rolled out Origin Range Requests, a self-service feature that optimises how large cacheable objects are delivered when clients ask for partial content. Built to replace the previous range-caching approach (which used fixed, manually tuned range sizes per zone and could waste bandwidth and processing), Origin Range Requests automatically handles the coordination of cached bytes, in-flight data, and new origin fetches. The result for large files and seekable content is more efficient delivery, with no need for customers to tune range sizes or contact support.
The implementation relies on fixed-size cache chunks. When a client requests a specific byte range, Cloudflare serves what is already cached and fetches only the missing portions from the origin in aligned chunks. The edge then composes the final 206 Partial Content response with accurate Content-Range and Content-Length headers, even if the data comes from a mix of cached, in-flight, and newly retrieved data.
A coordinator ensures consistency, validating that the origin responses match the requested range, the asset size remains stable, and the ETag is unchanged across subrequests. If the representation changes, an If-Range check prevents unsafe composition.
In production, Cloudflare started migrating high-impact workloads first, notably R2, with clear gains: faster p99 time to first byte (around half) and fewer bytes moved across data centres (about 6% week over week). To enable Origin Range Requests, customers create a Cache Rule and switch the mode to On; Cloudflare then handles the rest, with no changes required to normal cache eligibility.