In a standard HTTP GET request, the server transmits the entire resource from byte 0 to the end. For large media files (such as 4K video or multi-gigabyte zip archives), this makes seeking forward in a video impossible without downloading all preceding gigabytes. RFC 9110 defines HTTP Byte-Serving: the server advertises Accept-Ranges: bytes. The client can request an arbitrary slice of the resource using Range: bytes=10485760-20971519. The server responds with HTTP status 206 Partial Content, returning ONLY the requested 10 MB chunk along with Content-Range: bytes 10485760-20971519/104857600. When a user seeks to the middle of a 2-hour movie, the browser HTML5 video player requests only the byte range containing the target keyframe, enabling instant playback with zero bandwidth waste.

When downloading a file in multiple parallel chunks or resuming an interrupted download, there is a risk that the resource on the origin server was modified between requests. If a client blindly requests bytes 5000000-10000000 from a newly uploaded version of the file and stitches it to the first half from the previous version, the resulting file will be catastrophically corrupted. The If-Range header provides an atomic conditional check: the client sends If-Range: "etag-hash" or If-Range: Wed, 21 Oct 2026 07:28:00 GMT. If the resource matches the ETag/timestamp, the server returns 206 Partial Content with the requested range. If the file has changed, the server gracefully ignores the Range header and returns 200 OK with the ENTIRE updated file, seamlessly preventing hybrid corruption.

A client can request multiple non-contiguous slices of a resource in a single HTTP request by specifying comma-separated ranges: Range: bytes=0-1023, 5000000-5001023. When responding, the server cannot return a standard flat byte stream. Instead, it responds with 206 Partial Content and Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES. The response body is divided into MIME parts, each containing its own Content-Type and Content-Range headers separated by the boundary string, enabling PDF viewers to fetch page 1 and the index catalog concurrently in a single round-trip.

When thousands of users watch a video at different points, they send different Range requests (e.g. bytes 0-1MB, 50-51MB). By default, if a reverse proxy / CDN does not cache range requests, each request hits the origin backend directly, overloading origin storage. Conversely, if the CDN tries to download the entire 10GB file on the first range request, the user experiences massive Time-to-First-Byte (TTFB) delay. The Nginx ngx_http_slice_module solves this: it splits large files into fixed-size slices (e.g. slice 1m;). Each client range request is mapped to the corresponding 1MB slice files in the CDN cache. Uncached slices are fetched from origin on-demand and cached independently, achieving line-rate CDN cache hit ratios for adaptive bitrate streaming.