Hypertext Transfer Protocol (HTTP/1.1): Range Requests
Extracted elements (29)
A 206 response is cacheable by default unless otherwise indicated by explicit cache controls (per RFC 7234 Section 4.2.2). This allows partial content to be stored and reused without requiring explicit cache directives.
Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature can respond as if it is a normal GET request without impacting interoperability. Partial responses use a distinct status code so caches that do not implement the feature do not mistake them for full responses.
A client receiving a multipart 206 response MUST inspect the Content-Range header field in each body part to determine which range is enclosed; a client cannot rely on receiving the same ranges it requested, nor the same order.
Because servers are free to ignore Range, many implementations simply respond with 200 (OK) and the full representation rather than 416. Clients cannot depend on receiving a 416 response even when it would be appropriate.
Some implementations were coded to an early draft of the byteranges specification that used the media type multipart/x-byteranges, which is almost but not quite compatible with the standardized multipart/byteranges type. Additionally, some implementations handle a quoted boundary string incorrectly.
A client MUST NOT generate an If-Range header field containing a weak entity-tag, and MUST NOT generate one containing an HTTP-date unless the client has no entity-tag and the date is a strong validator. A server evaluating If-Range MUST use the strong comparison function for entity-tags.
A Content-Range field value is invalid if last-byte-pos is less than first-byte-pos, or if complete-length is less than or equal to last-byte-pos. The recipient of an invalid Content-Range MUST NOT attempt to recombine the received content with a stored representation.
A server MUST ignore a Range header field received with a request method other than GET. An origin server MUST ignore a Range header field containing a range unit it does not understand.
A server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple-part 206 response (it must appear in each part instead), and MUST NOT generate a multipart response to a request for a single range.
A server that supports range requests MAY ignore or reject a Range header field consisting of more than two overlapping ranges or many small ranges not in ascending order, as both indicate a broken client or a deliberate denial-of-service attack.
If a 206 response contains a Content-Range with a range unit the recipient does not understand, the recipient MUST NOT attempt to recombine it with a stored representation. A proxy that receives such a message SHOULD forward it downstream.
If the If-Range validator matches, the server SHOULD process the Range header field as requested. If the validator does not match, the server MUST ignore the Range header field and send the full representation.
Multiple partial responses to the same target resource can be combined only if they share the same strong validator. A client MAY combine them into a larger continuous range; if the union covers the entire representation, the client MUST process it as a complete 200 (OK) response.
Recipients MUST anticipate potentially large decimal numerals in first-byte-pos, last-byte-pos, and suffix-length and prevent parsing errors due to integer conversion overflows, since there is no predefined limit to the length of a payload.
The Range header field is evaluated only after evaluating precondition header fields defined in RFC 7232 and only if the result in absence of Range would be a 200 (OK) response; Range is ignored when a conditional GET would produce a 304 (Not Modified).
When generating a 206 response, the server MUST generate Date, Cache-Control, ETag, Expires, Content-Location, and Vary if those fields would have been sent in a 200 response, unless the request had an If-Range header (in which case other representation header fields SHOULD NOT be generated).
A suffix-byte-range-spec requests the last N bytes of a representation using the form '-suffix-length'. If the representation is shorter than suffix-length, the entire representation is used.
The 206 (Partial Content) status code indicates successful fulfillment of a range request. For a single range, the response MUST include a Content-Range header; for multiple ranges, it MUST use a multipart/byteranges payload with Content-Range in each body part.
The 416 (Range Not Satisfiable) status code indicates that no requested range overlaps the current extent of the resource, or that the set of ranges has been rejected as invalid or excessive. For byte-range requests, the sender SHOULD include a Content-Range with the current representation length.
The Accept-Ranges response header field allows a server to advertise support for range requests. A value of 'bytes' indicates byte-range support; a value of 'none' advises the client not to attempt a range request.
The If-Range header field allows a client to short-circuit a two-request resume sequence: if the representation is unchanged (validator matches), send only the requested range; otherwise send the entire representation. Its value is an entity-tag or HTTP-date.
The Range request header field modifies GET semantics to request transfer of one or more subranges of the selected representation. Its syntax is 'byte-ranges-specifier / other-ranges-specifier'.
The HTTP Range Unit Registry defines the namespace for range unit names. New registrations require IETF Review and must include a name, description, and pointer to specification. Initial entries are 'bytes' (a range of octets) and 'none' (reserved keyword indicating no ranges are supported).
The HTTP Status Code Registry has been updated to include 206 (Partial Content) and 416 (Range Not Satisfiable) as defined in this document.
The Message Headers registry has been updated to include permanent standard registrations for Accept-Ranges, Content-Range, If-Range, and Range HTTP header fields.
The multipart/byteranges Internet media type is registered with IANA. It requires a 'boundary' parameter, permits only 7bit/8bit/binary encoding, and is used by HTTP components supporting multiple ranges in a single request.
Unconstrained multiple range requests are susceptible to denial-of-service attacks because requesting many overlapping ranges requires minimal effort from the client but consumes disproportionate time, memory, and bandwidth on the server. Servers ought to ignore, coalesce, or reject egregious range requests, such as more than two overlapping ranges or many small ranges in a single set.
Byte ranges are expressed as 'bytes=byte-range-set', where each element is either a byte-range-spec ('first-byte-pos "-" [last-byte-pos]') or a suffix-byte-range-spec ('"-" suffix-length'). Byte offsets are zero-based and inclusive on both ends.
Content-Range syntax: 'bytes-unit SP (byte-range-resp / unsatisfied-range)' where byte-range-resp is 'first-byte-pos "-" last-byte-pos "/" (complete-length / "*")' and unsatisfied-range is '"*/" complete-length'. An asterisk for complete-length means the total length was unknown at generation time.