When someone seeks within a video or reads a small part of a large file, they need only a fraction of its contents. Does the CDN also transfer only that fraction behind the scenes?

On October 23, 2026, Cloudflare announced Origin Range Requests for all plans, removing customer range-size tuning. Official announcement

To evaluate it, separate the range returned to the client from the range fetched from the origin. That distinction explains both the work the feature handles and the checks that remain yours.

HTTP byte ranges and cache fetch units serve different purposes

A GET with Range: bytes=1024-2047 requests 1024 bytes: offsets start at zero and include both endpoints, so 2047 - 1024 + 1 = 1024. This illustrative calculation follows RFC 9110 byte-range semantics.

Cache storage need not use that same unit. Fixed-size subdivision also exists in the NGINX slice module, which includes the slice range in the cache key. Its documentation warns that excessively small slices increase memory use and open files. Smaller is not automatically better.

Origin Range Requests coordinates cached, in-flight, and missing data using Pingora chunks, sharing an existing fetch when it covers another request. Implementation explanation

The current origin request specification aligns fetches to 1 MiB boundaries. This example assumes an unencoded file of at least 1 MiB whose first chunk is uncached; it is not a captured trace.

Transfer	Example byte interval	Length
Client request	1024–2047	1 KiB
Possible origin fetch	0–1048575	1 MiB
Client response	1024–2047	1 KiB

Some overfetch remains. Operationally, do not use client response size as a substitute for origin transfer volume.

Combining partial responses requires a consistent origin

Every piece must belong to the same representation. For encoded content, HTTP ranges refer to encoded bytes, so offsets cannot simply carry over after decompression. This follows RFC 9110.

Cloudflare requests Accept-Encoding: identity. Cacheable origin 206 responses require matching Content-Range, accurate Content-Length, no Transfer-Encoding, unencoded content, consistent total size, and consistent ETag presence and value if supplied. Partial-response requirements

An origin returning a full 200 instead can still be used, but requires a complete download, as documented in the September 2, 2026 API announcement. Before enabling the feature, establish whether the target files actually produce partial origin responses.

Availability on every plan does not remove whole-file cache limits

Origin Range Requests preserves cache eligibility rules, applies size limits to the whole file, and does not support Cache Reserve. Cache Rules specification

As checked on October 24, 2026, cacheable file limits are 512 MB for Free, Pro, and Business, and a default 5 GB for Enterprise. Enterprise customers can request an increase.

For example, requesting 1 KiB from a 2 GB file does not make that file cacheable under a 512 MB limit. Establish whole-file eligibility before investigating how frequently clients request small portions.

Scope a Cache Rule, then measure latency and transfer volume

Enable Origin Range Requests in a Cache Rule scoped to the intended hostname or path; the API setting is origin_range_requests.mode: on. off disables generated origin range fetches while permitting ranges from complete cached files. default follows platform behavior; no extensions are enabled by default at the time of review. Mode definitions

The September 2, 2026 changelog already documents Rulesets API support. October 23 is the blog announcement date, not the first documented API availability date.

Cloudflare reports roughly halved R2 p99 TTFB, with a later improvement reducing tiered-cache traffic for R2 and similar workloads by about 6% week over week. TTFB measures time to the first byte, not download completion; these observations do not guarantee your improvement. Reported results

For rollout evaluation, compare identical files and request patterns before and after enabling it. Separate cold and warm caches, and track TTFB alongside origin bytes, request counts, and prematurely terminated responses. This is a proposed validation approach, not a benchmark performed for this article.

Returning to the opening question: a small client request need not mean an equally small upstream transfer. The operational decision shifts from selecting a slice size to validating eligible files and dependable origin responses. Once those conditions hold, evaluate both waiting time and transfer volume.

Source

• Title: Origin Range Requests: Serving large files without range-request tuning
• URL: https://blog.cloudflare.com/origin-range-requests/