Cloudflare announced self-service Origin Range Requests across all plans. The feature changes how partial-file requests are satisfied, aiming to reduce unnecessary large origin fetches when a client needs only a small section of a resource. Cloudflare official announcement
HTTP Range requests support video seeking and resuming interrupted downloads. Even a cache-oriented design can waste bandwidth and disk work when it fetches much more data than the client needs.
On this page
HTTP Range requests ask for selected bytes
Seeking within a video or resuming a large download can require only part of a file. A Range request identifies the desired bytes. When supported, the server commonly responds with 206 Partial Content and a Content-Range describing the returned interval. Distinguish this from a 200 response containing the complete representation when inspecting how a transfer was actually served.
Fetching a complete multi-gigabyte file for every small read wastes upstream work. Dividing everything into extremely small requests can create a different problem by increasing origin operations and storage activity. Efficient delivery requires coordinating bytes already cached, bytes currently being downloaded, and missing coverage rather than treating the entire object as simply cached or uncached.
Every combined segment must belong to the same representation
Partial responses can be combined safely only when they describe the same version of an object. If the origin changes while a download is in progress, combining old cached bytes with newly fetched bytes can corrupt the result. Representation validators such as ETags and the total object length matter because correctness takes priority over fetching each segment quickly.
Compression and other transformations also affect what a byte offset identifies. Review origin Range support, response headers, and transformation policies together. Enabling this feature does not make otherwise ineligible responses cacheable. Existing cache eligibility and access-control requirements still need review, particularly where application endpoints can return private or personalized content.
Evaluate a disk-image or model-file distribution path
For a hypothetical image server, test full downloads, resumption from an intermediate offset, and concurrent downloads of the same object. Compare requested and returned lengths and check the integrity of the completed file. Separate cold-cache tests from tests where some ranges are already present so that the results describe the actual cache conditions.
Record origin bytes alongside bytes delivered to clients to identify unnecessary upstream transfer. Do not use that ratio alone as the success criterion: first-byte latency, origin request count, and failure rate matter too. Repeat the test immediately after updating the origin object to catch mixed-version behavior that an ordinary speed test might miss.
Test partial downloads directly
- Check status codes and Content-Range for normal and partial requests.
- Measure origin traffic for first and repeated requests.
- Verify seeking, resume, and concurrent downloads do not truncate responses.
Record the existing cache policy and begin with one path. Expand only after comparing both origin load and user-facing latency.
Announcement reference date: 2026-10-23 · Checked: October 24, 2026
