Public media guide
HTTP Byte-Range Requests & CDN Edge Caching: How Modern Web Video Buffering Works
An in-depth architectural breakdown of RFC 7233 Range headers, 206 Partial Content responses, CDN chunk caching heuristics, seek latency minimization, and edge delivery pipelines.
Delivering multi-gigabyte media files over HTTP without stalling or unbounded memory consumption requires specialized network transport mechanics. When a user clicks play or scrubs forward on a video timeline, modern HTML5 players do not fetch the entire asset in a single continuous transfer.
Instead, web video delivery relies on RFC 7233: Range Requests in HTTP. By issuing partitioned byte-range requests, browser media engines (such as Chrome's NuPlayer or Safari's AVPlayer) fetch only the precise byte offsets needed to populate immediate playback buffers.
At scale, these granular requests interact with Content Delivery Network (CDN) edge nodes that cache, coalesce, and route slices of video data. Understanding how edge servers interpret the Range header, handle Cache-Control directives, and avoid 416 Range Not Satisfiable errors is essential for building resilient web video infrastructure.
In this technical guide, we analyze the end-to-end network handshake of 206 Partial Content, examine how CDN tiered caching partitions media assets, and demonstrate production Nginx proxy configurations for smooth video seeking.
1. The RFC 7233 Handshake: Headers, Offsets, and 206 Status
When an HTML5 video tag requests a media URL, the browser first issues an initial probe or preliminary range request to read file headers, container metadata (such as the MP4 moov atom), and total file size.
- Initial Request: The client sends Range: bytes=0- or Range: bytes=0-1 to verify server capabilities without downloading the full payload.
- Server Confirmation: If supported, the origin responds with HTTP/1.1 206 Partial Content, Accept-Ranges: bytes, and Content-Range: bytes 0-1048575/52428800 (offset start, offset end, and total content length).
- Sequential Buffering: Media Source Extensions (MSE) read sequential 1 MB to 4 MB chunks and feed them into demuxer source buffers.
- Scrubbing / Seeking: When a user seeks to minute 15, the player calculates the estimated byte offset from the index table and instantly issues a new Range: bytes=35000000- request, avoiding re-buffering intermediate footage.
2. CDN Edge Caching & The Slice Module Mechanism
Caching byte-range responses at CDN edge points introduces unique architectural challenges. If thousands of users seek to arbitrary offsets, a standard cache could store fragmented, overlapping slices, causing cache fragmentation and redundant origin load.
- Range Slicing: Modern CDNs (like Cloudflare, Fastly, and Akamai) break large assets into uniform sub-chunks (typically 1 MB or 2 MB slices) internally.
- Coalescing: Multiple overlapping client range requests are satisfied from common cached slices, maximizing edge cache hit ratios (CHR) above 95%.
- ETag & Last-Modified Consistency: If the origin file changes without cache invalidation, inconsistent byte offsets corrupt the demuxer pipeline, producing playback stalls.
3. Nginx Origin Configuration for Resilient Streaming
Ensuring your origin server or reverse proxy supports streaming requires explicitly disabling proxy buffering for media endpoints and passing range headers downstream.
- proxy_set_header Range $http_range: Passes incoming client range headers through to upstream storage buckets (e.g., S3 or local disk).
- proxy_cache_slice: Instructs Nginx to partition large files into internal 1 MB slices for efficient cache retention.
- add_header Accept-Ranges bytes: Explicitly declares byte-range capability so mobile browsers do not fall back to monolithic full-file downloads.
Format & Use Table
| Delivery Mechanism | Monolithic HTTP 200 | HTTP 206 Range Streaming | HLS / DASH Adaptive Slices |
|---|---|---|---|
| Transfer Method | Single continuous stream | Client-driven byte ranges | Manifest + discrete media segments (.ts/.m4s) |
| Seek Latency | High (must buffer from start or wait) | Instant (fetches target offset) | Near-instant (fetches target 2s-6s segment) |
| Bandwidth Waste | High if user abandons early | Low (only buffered slices loaded) | Minimal (only requested segments loaded) |
| Origin Server Load | High connection concurrency | Short stateless request bursts | Fully edge-cacheable static files |
| Supported Media | Basic MP4/WebM progressive | HTML5 video/audio progressive | Adaptive bitrate live & VOD |
Step-by-Step Workflow
Inspect Range headers using curl: curl -I -H "Range: bytes=0-1024" https://example.com/video.mp4
Verify 206 status and Content-Range in response: HTTP/2 206, content-range: bytes 0-1024/20485900
Simulate a timeline scrub with curl: curl -r 10485760-12582912 -o chunk.bin https://example.com/video.mp4
Configure Nginx slice caching: proxy_cache_slice 2m; proxy_set_header Range $slice_range;
Frequently Asked Questions
What causes HTTP 416 Range Not Satisfiable errors?
HTTP 416 occurs when a client requests byte offsets beyond the actual file size (e.g. requesting bytes=5000000- on a 4 MB file), or if the file was modified on the origin while a client held an outdated Content-Length.
Why won't iOS Safari play MP4 video without 206 Partial Content support?
Apple Safari on iOS strictly requires servers to support byte-range requests. If an origin server responds with HTTP 200 instead of HTTP 206 to the initial probe, iOS will display a crossed-out play icon and refuse playback.
