HTTP Range Requests Use Fixed Cache Chunks, Not Tuning
HTTP range requests let a client ask for selected bytes from a file instead of downloading the entire object. In a technical account dated October 23, 2026, Cloudflare described a new implementation that uses the fixed-size chunks already employed by its Pingora cache rather than requiring customers to choose a range size. The change addresses a broader infrastructure problem: one manually selected slice size cannot efficiently serve every video seek, resumed download, package fetch, file size and cache layout.
A range request is particularly useful for large objects. A video player can fetch data around a new playback position, while a download manager can resume an interrupted transfer. Package managers may retrieve only part of an artifact, and clients can examine the end of a file without first transferring everything before it. The client decides whether to send the request, using the Range header, which specifies the required byte positions. Cloudflare says it does not alter that client request. Origin Range Requests instead changes how its network obtains and returns the requested data.
When the origin server, meaning the system holding the original file, supports the request, it can return the HTTP status `206 Partial Content`. A `Content-Range` response header identifies which bytes were supplied and the complete file size. Cloudflare gives an example covering bytes 1048576 through 2097151 of a 524288000-byte file, with a `Content-Length` of 1048576 bytes. That last header tells the client how much data is in the response.
Cloudflare's previous implementation used static configuration for each zone, its configuration boundary for a website. It resembled the cache-slicing method described in an nginx blog post: every client request was mapped onto fixed-size sections of a file, while administrators configured both the section size and applicable file extensions. A cache is temporary storage that keeps previously retrieved data closer to clients so it can be served again without another complete origin transfer.
That approach forced a difficult tradeoff. Small configured ranges generated many small requests to the origin and increased memory pressure while Cloudflare merged concurrent requests in memory. Large ranges could make the network download substantially more data than the client had requested. Because the selected size formed part of the cache key, the identifier used to find a stored response, changing that setting also invalidated existing entries.
Concurrency created another problem. Requests mapped into the same configured range could block one another even when the clients wanted bytes far apart within that section. Cloudflare's nginx-based cache also could not safely combine range caching with concurrent streaming, which lets clients start reading an object from cache while the cache is still receiving it. Enabling both could truncate responses. As a result, a complete range had to arrive before a client could read it, and a popular file required a separate origin fetch for each range.
Over-fetching could propagate through several layers. Unneeded bytes might travel from the origin to one data centre, move between cache tiers and then continue towards the client. Each step increased the wasted transfer. Cloudflare concluded that no single configured range size worked equally well for a short seek, sequential download, large media object, every origin and every cache topology. These internal limitations consequently became a configuration burden for customers.
The move from nginx to a Pingora-based caching server provided a different model. Pingora already stores each cached file on disk as fixed-size chunks so interrupted downloads can resume. Origin Range Requests reuses those chunks. The edge, meaning the network location serving the client, first checks which requested bytes are present. It returns available data directly, then asks the origin for missing ranges aligned with chunk boundaries. Newly retrieved data goes into the same chunks used for ordinary cached objects, while the client receives only the bytes it requested.
For example, a client request for bytes 150 through 250 may cause the cache to fetch the complete aligned chunk containing that interval. The downstream response still includes only bytes 150 through 250. This does not remove all extra transfer: a request smaller than a chunk can still require the entire containing chunk, and ranges that do not align with boundaries require additional processing. Cloudflare's stated advantage is that this work is bounded and predictable rather than controlled by a customer-selected size with potentially unpredictable effects on the cache and origin.
The difficult engineering task is not parsing the Range header but assembling a correct response when its bytes are distributed across disk, an origin response and downloads already in progress. Cloudflare says the edge first reads the asset headers and range-coverage metadata, which records which portions are available. It reads what it can from disk or streaming memory, fetches missing coverage through aligned origin requests, writes completed bytes, updates the metadata and combines all pieces. It then sets `Content-Range` and `Content-Length` for the client response.
For organisations deciding where to run the surrounding workload, AEU Data offers European cloud and data infrastructure.
The transferable lesson is that partial-file delivery works best when its unit of retrieval matches the cache's native storage unit. That removes a fragile customer-facing tuning control, limits the cost of small or unaligned requests and allows cached, newly fetched and in-flight data to contribute to one response.