Fetching part of a resource
HTTP range requests let a client download just a slice of a resource — the
foundation of resumable downloads, video seeking and parallel chunked
transfers. The client asks with a Range header, the server answers with
206 Partial Content and a Content-Range, and advertises support up front
with Accept-Ranges. This reference covers the full header set with a parser
that resolves any Range value against a resource size.
How it works
A Range header names one or more byte ranges in the form first-last:
Range: bytes=0-499
Range: bytes=500- (open-ended: 500 to the last byte)
Range: bytes=-200 (suffix: the final 200 bytes)
Range: bytes=0-499, 1000-1499 (multiple ranges → multipart/byteranges)
Positions are zero-based and inclusive. The server clamps a last value that
runs past the end, treats a first at or beyond the size as unsatisfiable
(416), and echoes the actual slice in Content-Range: bytes first-last/size.
A single range yields one body; multiple ranges yield a multipart/byteranges
response. An If-Range header makes the partial fetch conditional so a changed
resource falls back to a full 200.
Tips and notes
Content-Lengthon a206is the size of the returned slice, not the whole file.- Use
If-Rangewith the resource’sETagto safely resume an interrupted download. 416responses should carryContent-Range: bytes */<total>so clients learn the size.- Only the
bytesunit is widely supported; servers ignore unknown range units.