HTTP Range
An HTTP/1.1 protocol mechanism that allows a client to request a specific byte range of a resource. The server returns a 206 status code when it supports the request, and it is used in scenarios such as resumable downloads.
Timeline (last 90 days)
The HTTP Range request mechanism was introduced by HTTP/1.1, allowing clients to fetch only a certain byte range of a resource via the Range request header.
When a server supports Range requests, it returns the 206 Partial Content status code and indicates the actually returned range via the Content-Range header; Accept-Ranges: bytes indicates the server supports byte range requests.
A browser cannot rashly resume a download based solely on the Accept-Ranges header; it also needs to make a secondary judgment based on the response status code and file verification information, because some servers claim support but have flawed implementations, and some ignore Range and return 200 OK with the full file.
A weak ETag cannot be used for validation of byte range requests, because it only guarantees semantic equivalence rather than byte-level consistency.
Multi-connection downloading splits a file into multiple parallel Range intervals fetched simultaneously, each interval having its own completion progress and requiring independent state management.
Intermediary networks (such as proxies and enterprise firewalls) may rewrite or cache Range requests, causing the byte range returned on resume to not match the request.
Resumable downloads fail when the server does not support Range, the file has been modified, or the download uses an encrypted/authenticated one-time URL.
All Facts (7)
The HTTP Range request mechanism was introduced by HTTP/1.1, allowing clients to fetch only a certain byte range of a resource via the Range request header.
50%UnverifiedWhen a server supports Range requests, it returns the 206 Partial Content status code and indicates the actually returned range via the Content-Range header; Accept-Ranges: bytes indicates the server supports byte range requests.
50%UnverifiedA browser cannot rashly resume a download based solely on the Accept-Ranges header; it also needs to make a secondary judgment based on the response status code and file verification information, because some servers claim support but have flawed implementations, and some ignore Range and return 200 OK with the full file.
50%UnverifiedA weak ETag cannot be used for validation of byte range requests, because it only guarantees semantic equivalence rather than byte-level consistency.
50%UnverifiedMulti-connection downloading splits a file into multiple parallel Range intervals fetched simultaneously, each interval having its own completion progress and requiring independent state management.
50%UnverifiedIntermediary networks (such as proxies and enterprise firewalls) may rewrite or cache Range requests, causing the byte range returned on resume to not match the request.
50%UnverifiedResumable downloads fail when the server does not support Range, the file has been modified, or the download uses an encrypted/authenticated one-time URL.
50%