Origin Range Requests: Cloudflare serves large files without tuning

Cloudflare announced a new, self-service feature called Origin Range Requests that changes how the CDN satisfies HTTP range requests for parts of large files, according to the Cloudflare Blog. The new implementation removes the old customer-facing range-size setting, uses fixed-size cache chunks, and aims to reduce extra data transfer while serving only the bytes a client requested.

Why range requests caused trouble

Range requests let a client ask for part of a file instead of the whole resource, for example when a video player seeks or a download manager resumes. Cloudflare previously supported range caching through a zone-level configuration that mapped client requests to fixed ranges. That approach created a hard tradeoff: small configured ranges produced many tiny origin requests and memory pressure, while large configured ranges caused the CDN to fetch far more data from the origin than the client needed. The previous implementation could also block concurrent requests that fell inside the same configured range and could not combine range caching with concurrent streaming.

According to the Cloudflare Blog, these behaviors sometimes forced large transfers between data centers and created unpredictable load on origins. For example, Cloudflare reported that R2 had a configured range size of 64 MiB under the old system, and small reads that crossed a boundary could cause transfers many times larger than the bytes the client requested.

How Origin Range Requests work

Cloudflare rebuilt its cache logic on a new caching server, Pingora, which already stores objects on disk in fixed-size chunks. Rather than expose a tunable range size to customers, Cloudflare aligns origin fetches to the cache chunk boundaries. When a client requests a byte range, the edge checks what bytes are already cached, serves those bytes, and fetches missing chunks from the origin aligned to the cache's chunk boundaries. The edge then returns only the bytes the client asked for.

The implementation coordinates cached data, in-flight downloads, and new origin responses so one request can be satisfied by combining cached prefixes, downloads in progress, and newly fetched suffixes. If an existing download covers another request's bytes, that request can attach to the in-flight download instead of starting a new origin fetch. Cloudflare says the coordinator also validates that all bytes belong to the same representation, honors If-Range semantics, and avoids composing ranges when decompressing would change the byte ranges. The HTTP behavior remains standard: satisfiable ranges get 206 Partial Content, unsatisfiable ranges get 416 Range Not Satisfiable, and responses that cannot be safely ranged are served as full representations.

Measured effects so far

Cloudflare moved existing users of the old range-caching feature to the new implementation before making it generally available, starting with workloads that caused the most operational pain. On R2 and similar workloads, Cloudflare reports that p99 time to first byte dropped by about half, and a follow-up change lowered tiered cache traffic by roughly 6% week over week. Those reductions imply less cross-data-center movement of large objects and more predictable cost and performance behavior according to the Cloudflare Blog.

Practical steps for owners and operators

• Consider whether you serve large objects that clients might request by range, such as video files, large downloads, or resumable artifacts. If so, this feature is relevant.
• Enable Origin Range Requests by creating a Cache Rule, because the feature is self-service and available on all plans. "There's no range size to tune and no need to contact support," according to the Cloudflare Blog.
• After enabling the feature, monitor your cache hit patterns, origin egress, and client latency to confirm the change reduces unnecessary transfers in your environment.
• Check any integrations that rely on specific range behavior, and test resumable downloads or stream seeks to ensure clients receive the expected status codes and Content-Range headers.
• If you want help implementing or testing this on WordPress or Formidable Forms sites, consider contacting a developer who specializes in those platforms via our contact page: Running WordPress or Formidable Forms? Get help from a Formidable Masterminds developer.

What this means for small teams and nonprofits

For small organizations that host large media or deliver large artifacts, the change should reduce unexpected bandwidth and make partial reads more efficient without requiring per-zone tuning. Because the implementation bounds the extra work to cache chunk sizes instead of customer-selected ranges, operators will see more predictable behavior when clients make small seeks or when traffic is spiky. The feature also aims to reduce the number of unnecessary origin fetches during bursts by letting concurrent requests attach to in-flight downloads.

Cloudflare's writeup covers technical details of alignment, validation, and how the coordinator composes bytes from different sources. If you rely on large-file delivery, enabling Origin Range Requests and observing real traffic patterns is a simple next step to determine whether you get the reported improvements in latency and cross-data-center traffic.