Cloudflare's new range-request caching puts origin traffic in focus

On October 23, Cloudflare announced self-service Origin Range Requests on all plans. Customers select matching traffic through Cache Rules, while Cloudflare coordinates how partial file data is fetched and cached without a customer-selected range size.

The company identifies seekable video, resumable downloads, software repositories and other large-file workloads as intended uses. It says the feature changes how it satisfies client requests, rather than changing which portion the client asks for.

The distinction matters to a business hosting training media or distributing large files: the user-facing action and the upstream transfer are separate parts of the delivery path. The announcement describes a new implementation, not a measured outcome for every website.

HTTP's Range request header lets a client ask for part of a representation. RFC 9110 defines 206 Partial Content responses and the Content-Range field used to describe the returned portion. It also permits servers to ignore a Range header.

That means a request for a portion is not, on its own, proof that every server in the path transferred only that portion. Cloudflare's documentation says an origin that ignores its generated Range request can return a complete 200 OK response. Cloudflare can use that response, but must download the complete file.

For a delivery review, the response observed by the client and the request recorded at the origin therefore answer different questions. Both can be valid observations without showing identical byte counts.

Cloudflare's range-request reference says it aligns origin fetches to 1 MiB cache boundaries. Its example shows that a 1 KiB client request may lead to a 1 MiB origin fetch. One client request can also become several origin requests, with ranges different from the client's header.

The same reference says Origin Range Requests do not make an otherwise ineligible request or response cacheable. Maximum cacheable file size is checked against the whole object, rather than just the requested slice. Cache Reserve is not supported with this feature.

Those details make eligibility, origin behavior and request accounting relevant to an evaluation. A setting name alone does not establish that a specific file uses the intended delivery path.

Cloudflare's cache-response guide describes HIT as a resource found in its cache. MISS means an eligible response was absent at request time and was served from the origin. These labels explain cache handling; they are not a complete accounting of a workload's upstream bytes.

A useful internal comparison could keep the file version and client action consistent while recording the requested interval, actual response, cache status, origin requests and transferred bytes. This is an editorial evaluation approach, not a report of tests performed for this article.

Consider a hypothetical team distributing a large onboarding video. A viewer who jumps to the final section and a viewer who watches from the beginning exercise different access patterns. Treating both simply as one video view would hide the distinction that the new feature is designed to address.

The team could discuss the following questions before interpreting any trial. The scenario reports no OrangeHat deployment, customer experience or savings.