Accept-Ranges
Resumable downloads and byte-range fetching depend on the server advertising range support. The Accept-Ranges response header indicates a server supports partial requests for the resource.
Usage
The Accept-Ranges header tells clients the server accepts Range requests, enabling partial downloads of a resource. This is essential for resuming interrupted file transfers, streaming media from a specific position, and fetching segments of large files on demand.
When a client sends a Range request, the server returns a 206 Partial Content response containing only the requested byte segment. The Content-Range response header specifies the exact byte range and total size of the resource.
A malformed Range header is ignored, and the server returns the full resource with a normal response. When the requested ranges fall outside the resource boundaries, the server responds with 416 Range Not Satisfiable.
Directives
bytes
The server accepts byte-range requests. This is the only range unit defined by HTTP and the most common value for the header.
none
The server does not support range requests for this
resource. Sending none explicitly advises clients not
to attempt range requests.
Example
A server indicating support for byte-range requests. Download managers and media players use this signal to request specific portions of a file.
Accept-Ranges: bytes
A server explicitly disabling range requests. Clients receiving this value download the full resource in a single request.
Accept-Ranges: none
A typical response for a downloadable file, combining the range support indicator with the content length. A client interrupted at byte 5000 resumes from the point of failure.
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 1048576
Content-Type: application/octet-stream
What servers advertise in practice
The header is advisory in both directions. Clients
send range requests without having seen the header,
and a server advertising bytes remains free to
answer any particular request with a full 200.
nginx adds Accept-Ranges: bytes only when the
response is a plain 200 with a known content
length and range support enabled. On-the-fly
compression removes the advertisement: gzip on
strips the header, since ranges over a body compressed
per-request have no stable byte positions. nginx
never sends the none token, omitting the header
instead.
Apache advertises on statically served files, and is
one of the few servers emitting the reserved token,
answering Accept-Ranges: none when MaxRanges is
set to none. Dynamic responses through CGI or a
proxied backend carry no advertisement unless the
application adds one.
Download managers and media players are the consumers. Safari and iOS depend on range requests for video seeking, so an MP4 served through a cache downgrading strong ETags to weak ones fails to play there, showing a black screen while other browsers cope. Cloudflare documents dedicated cache rules for exactly this case, keeping strong ETags on MP4 paths.
Cloudflare's cache answers range requests with 206 when the origin response carried a Content-Length, and falls back to a full 200 when the length is unknown.