From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7233.txt | 1403 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1403 insertions(+) create mode 100644 doc/rfc/rfc7233.txt (limited to 'doc/rfc/rfc7233.txt') diff --git a/doc/rfc/rfc7233.txt b/doc/rfc/rfc7233.txt new file mode 100644 index 0000000..af212e7 --- /dev/null +++ b/doc/rfc/rfc7233.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 7233 Adobe +Obsoletes: 2616 Y. Lafon, Ed. +Category: Standards Track W3C +ISSN: 2070-1721 J. Reschke, Ed. + greenbytes + June 2014 + + + Hypertext Transfer Protocol (HTTP/1.1): Range Requests + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypertext information + systems. This document defines range requests and the rules for + constructing and combining responses to those requests. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7233. + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 1] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 2] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Conformance and Error Handling .............................4 + 1.2. Syntax Notation ............................................4 + 2. Range Units .....................................................5 + 2.1. Byte Ranges ................................................5 + 2.2. Other Range Units ..........................................7 + 2.3. Accept-Ranges ..............................................7 + 3. Range Requests ..................................................8 + 3.1. Range ......................................................8 + 3.2. If-Range ...................................................9 + 4. Responses to a Range Request ...................................10 + 4.1. 206 Partial Content .......................................10 + 4.2. Content-Range .............................................12 + 4.3. Combining Ranges ..........................................14 + 4.4. 416 Range Not Satisfiable .................................15 + 5. IANA Considerations ............................................16 + 5.1. Range Unit Registry .......................................16 + 5.1.1. Procedure ..........................................16 + 5.1.2. Registrations ......................................16 + 5.2. Status Code Registration ..................................17 + 5.3. Header Field Registration .................................17 + 5.4. Internet Media Type Registration ..........................17 + 5.4.1. Internet Media Type multipart/byteranges ...........18 + 6. Security Considerations ........................................19 + 6.1. Denial-of-Service Attacks Using Range .....................19 + 7. Acknowledgments ................................................19 + 8. References .....................................................20 + 8.1. Normative References ......................................20 + 8.2. Informative References ....................................20 + Appendix A. Internet Media Type multipart/byteranges ..............21 + Appendix B. Changes from RFC 2616 .................................22 + Appendix C. Imported ABNF .........................................22 + Appendix D. Collected ABNF ........................................23 + Index .............................................................24 + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 3] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +1. Introduction + + Hypertext Transfer Protocol (HTTP) clients often encounter + interrupted data transfers as a result of canceled requests or + dropped connections. When a client has stored a partial + representation, it is desirable to request the remainder of that + representation in a subsequent request rather than transfer the + entire representation. Likewise, devices with limited local storage + might benefit from being able to request only a subset of a larger + representation, such as a single page of a very large document, or + the dimensions of an embedded image. + + This document defines HTTP/1.1 range requests, partial responses, and + the multipart/byteranges media type. Range requests are an OPTIONAL + feature of HTTP, designed so that recipients not implementing this + feature (or not supporting it for the target resource) can respond as + if it is a normal GET request without impacting interoperability. + Partial responses are indicated by a distinct status code to not be + mistaken for full responses by caches that might not implement the + feature. + + Although the range request mechanism is designed to allow for + extensible range types, this specification only defines requests for + byte ranges. + +1.1. Conformance and Error Handling + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Conformance criteria and considerations regarding error handling are + defined in Section 2.5 of [RFC7230]. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with a list extension, defined in Section 7 of + [RFC7230], that allows for compact definition of comma-separated + lists using a '#' operator (similar to how the '*' operator indicates + repetition). Appendix C describes rules imported from other + documents. Appendix D shows the collected grammar with all list + operators expanded to standard ABNF notation. + + + + + + + + +Fielding, et al. Standards Track [Page 4] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +2. Range Units + + A representation can be partitioned into subranges according to + various structural units, depending on the structure inherent in the + representation's media type. This "range unit" is used in the + Accept-Ranges (Section 2.3) response header field to advertise + support for range requests, the Range (Section 3.1) request header + field to delineate the parts of a representation that are requested, + and the Content-Range (Section 4.2) payload header field to describe + which part of a representation is being transferred. + + range-unit = bytes-unit / other-range-unit + +2.1. Byte Ranges + + Since representation data is transferred in payloads as a sequence of + octets, a byte range is a meaningful substructure for any + representation transferable over HTTP (Section 3 of [RFC7231]). The + "bytes" range unit is defined for expressing subranges of the data's + octet sequence. + + bytes-unit = "bytes" + + A byte-range request can specify a single range of bytes or a set of + ranges within a single representation. + + byte-ranges-specifier = bytes-unit "=" byte-range-set + byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) + byte-range-spec = first-byte-pos "-" [ last-byte-pos ] + first-byte-pos = 1*DIGIT + last-byte-pos = 1*DIGIT + + The first-byte-pos value in a byte-range-spec gives the byte-offset + of the first byte in a range. The last-byte-pos value gives the + byte-offset of the last byte in the range; that is, the byte + positions specified are inclusive. Byte offsets start at zero. + + Examples of byte-ranges-specifier values: + + o The first 500 bytes (byte offsets 0-499, inclusive): + + bytes=0-499 + + o The second 500 bytes (byte offsets 500-999, inclusive): + + bytes=500-999 + + + + + +Fielding, et al. Standards Track [Page 5] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + A byte-range-spec is invalid if the last-byte-pos value is present + and less than the first-byte-pos. + + A client can limit the number of bytes requested without knowing the + size of the selected representation. If the last-byte-pos value is + absent, or if the value is greater than or equal to the current + length of the representation data, the byte range is interpreted as + the remainder of the representation (i.e., the server replaces the + value of last-byte-pos with a value that is one less than the current + length of the selected representation). + + A client can request the last N bytes of the selected representation + using a suffix-byte-range-spec. + + suffix-byte-range-spec = "-" suffix-length + suffix-length = 1*DIGIT + + If the selected representation is shorter than the specified + suffix-length, the entire representation is used. + + Additional examples, assuming a representation of length 10000: + + o The final 500 bytes (byte offsets 9500-9999, inclusive): + + bytes=-500 + + Or: + + bytes=9500- + + o The first and last bytes only (bytes 0 and 9999): + + bytes=0-0,-1 + + o Other valid (but not canonical) specifications of the second 500 + bytes (byte offsets 500-999, inclusive): + + bytes=500-600,601-999 + bytes=500-700,601-999 + + If a valid byte-range-set includes at least one byte-range-spec with + a first-byte-pos that is less than the current length of the + representation, or at least one suffix-byte-range-spec with a + non-zero suffix-length, then the byte-range-set is satisfiable. + Otherwise, the byte-range-set is unsatisfiable. + + + + + + +Fielding, et al. Standards Track [Page 6] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + In the byte-range syntax, first-byte-pos, last-byte-pos, and + suffix-length are expressed as decimal number of octets. Since there + is no predefined limit to the length of a payload, recipients MUST + anticipate potentially large decimal numerals and prevent parsing + errors due to integer conversion overflows. + +2.2. Other Range Units + + Range units are intended to be extensible. New range units ought to + be registered with IANA, as defined in Section 5.1. + + other-range-unit = token + +2.3. Accept-Ranges + + The "Accept-Ranges" header field allows a server to indicate that it + supports range requests for the target resource. + + Accept-Ranges = acceptable-ranges + acceptable-ranges = 1#range-unit / "none" + + An origin server that supports byte-range requests for a given target + resource MAY send + + Accept-Ranges: bytes + + to indicate what range units are supported. A client MAY generate + range requests without having received this header field for the + resource involved. Range units are defined in Section 2. + + A server that does not support any kind of range request for the + target resource MAY send + + Accept-Ranges: none + + to advise the client not to attempt a range request. + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 7] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +3. Range Requests + +3.1. Range + + The "Range" header field on a GET request modifies the method + semantics to request transfer of only one or more subranges of the + selected representation data, rather than the entire selected + representation data. + + Range = byte-ranges-specifier / other-ranges-specifier + other-ranges-specifier = other-range-unit "=" other-range-set + other-range-set = 1*VCHAR + + A server MAY ignore the Range header field. However, origin servers + and intermediate caches ought to support byte ranges when possible, + since Range supports efficient recovery from partially failed + transfers and partial retrieval of large representations. 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 that contains a + range unit it does not understand. A proxy MAY discard a Range + header field that contains a range unit it does not understand. + + A server that supports range requests MAY ignore or reject a Range + header field that consists of more than two overlapping ranges, or a + set of many small ranges that are not listed in ascending order, + since both are indications of either a broken client or a deliberate + denial-of-service attack (Section 6.1). A client SHOULD NOT request + multiple ranges that are inherently less efficient to process and + transfer than a single range that encompasses the same data. + + A client that is requesting multiple ranges SHOULD list those ranges + in ascending order (the order in which they would typically be + received in a complete representation) unless there is a specific + need to request a later part earlier. For example, a user agent + processing a large representation with an internal catalog of parts + might need to request later parts first, particularly if the + representation consists of pages stored in reverse order and the user + agent wishes to transfer one page at a time. + + The Range header field is evaluated after evaluating the precondition + header fields defined in [RFC7232], and only if the result in absence + of the Range header field would be a 200 (OK) response. In other + words, Range is ignored when a conditional GET would result in a 304 + (Not Modified) response. + + + + + +Fielding, et al. Standards Track [Page 8] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + The If-Range header field (Section 3.2) can be used as a precondition + to applying the Range header field. + + If all of the preconditions are true, the server supports the Range + header field for the target resource, and the specified range(s) are + valid and satisfiable (as defined in Section 2.1), the server SHOULD + send a 206 (Partial Content) response with a payload containing one + or more partial representations that correspond to the satisfiable + ranges requested, as defined in Section 4. + + If all of the preconditions are true, the server supports the Range + header field for the target resource, and the specified range(s) are + invalid or unsatisfiable, the server SHOULD send a 416 (Range Not + Satisfiable) response. + +3.2. If-Range + + If a client has a partial copy of a representation and wishes to have + an up-to-date copy of the entire representation, it could use the + Range header field with a conditional GET (using either or both of + If-Unmodified-Since and If-Match.) However, if the precondition + fails because the representation has been modified, the client would + then have to make a second request to obtain the entire current + representation. + + The "If-Range" header field allows a client to "short-circuit" the + second request. Informally, its meaning is as follows: if the + representation is unchanged, send me the part(s) that I am requesting + in Range; otherwise, send me the entire representation. + + If-Range = entity-tag / HTTP-date + + A client MUST NOT generate an If-Range header field in a request that + does not contain a Range header field. A server MUST ignore an + If-Range header field received in a request that does not contain a + Range header field. An origin server MUST ignore an If-Range header + field received in a request for a target resource that does not + support Range requests. + + A client MUST NOT generate an If-Range header field containing an + entity-tag that is marked as weak. A client MUST NOT generate an + If-Range header field containing an HTTP-date unless the client has + no entity-tag for the corresponding representation and the date is a + strong validator in the sense defined by Section 2.2.2 of [RFC7232]. + + A server that evaluates an If-Range precondition MUST use the strong + comparison function when comparing entity-tags (Section 2.3.2 of + [RFC7232]) and MUST evaluate the condition as false if an HTTP-date + + + +Fielding, et al. Standards Track [Page 9] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + validator is provided that is not a strong validator in the sense + defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be + distinguished from a valid HTTP-date by examining the first two + characters for a DQUOTE. + + If the validator given in the If-Range header field matches the + current validator for the selected representation of the target + resource, then the server SHOULD process the Range header field as + requested. If the validator does not match, the server MUST ignore + the Range header field. Note that this comparison by exact match, + including when the validator is an HTTP-date, differs from the + "earlier than or equal to" comparison used when evaluating an + If-Unmodified-Since conditional. + +4. Responses to a Range Request + +4.1. 206 Partial Content + + The 206 (Partial Content) status code indicates that the server is + successfully fulfilling a range request for the target resource by + transferring one or more parts of the selected representation that + correspond to the satisfiable ranges found in the request's Range + header field (Section 3.1). + + If a single part is being transferred, the server generating the 206 + response MUST generate a Content-Range header field, describing what + range of the selected representation is enclosed, and a payload + consisting of the range. For example: + + HTTP/1.1 206 Partial Content + Date: Wed, 15 Nov 1995 06:25:24 GMT + Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT + Content-Range: bytes 21010-47021/47022 + Content-Length: 26012 + Content-Type: image/gif + + ... 26012 bytes of partial image data ... + + If multiple parts are being transferred, the server generating the + 206 response MUST generate a "multipart/byteranges" payload, as + defined in Appendix A, and a Content-Type header field containing the + multipart/byteranges media type and its required boundary parameter. + To avoid confusion with single-part responses, a server MUST NOT + generate a Content-Range header field in the HTTP header section of a + multiple part response (this field will be sent in each part + instead). + + + + + +Fielding, et al. Standards Track [Page 10] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + Within the header area of each body part in the multipart payload, + the server MUST generate a Content-Range header field corresponding + to the range being enclosed in that body part. If the selected + representation would have had a Content-Type header field in a 200 + (OK) response, the server SHOULD generate that same Content-Type + field in the header area of each body part. For example: + + HTTP/1.1 206 Partial Content + Date: Wed, 15 Nov 1995 06:25:24 GMT + Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT + Content-Length: 1741 + Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES + + --THIS_STRING_SEPARATES + Content-Type: application/pdf + Content-Range: bytes 500-999/8000 + + ...the first range... + --THIS_STRING_SEPARATES + Content-Type: application/pdf + Content-Range: bytes 7000-7999/8000 + + ...the second range + --THIS_STRING_SEPARATES-- + + When multiple ranges are requested, a server MAY coalesce any of the + ranges that overlap, or that are separated by a gap that is smaller + than the overhead of sending multiple parts, regardless of the order + in which the corresponding byte-range-spec appeared in the received + Range header field. Since the typical overhead between parts of a + multipart/byteranges payload is around 80 bytes, depending on the + selected representation's media type and the chosen boundary + parameter length, it can be less efficient to transfer many small + disjoint parts than it is to transfer the entire selected + representation. + + A server MUST NOT generate a multipart response to a request for a + single range, since a client that does not request multiple parts + might not support multipart responses. However, a server MAY + generate a multipart/byteranges payload with only a single body part + if multiple ranges were requested and only one range was found to be + satisfiable or only one range remained after coalescing. A client + that cannot process a multipart/byteranges response MUST NOT generate + a request that asks for multiple ranges. + + When a multipart response payload is generated, the server SHOULD + send the parts in the same order that the corresponding + byte-range-spec appeared in the received Range header field, + + + +Fielding, et al. Standards Track [Page 11] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + excluding those ranges that were deemed unsatisfiable or that were + coalesced into other ranges. A client that receives a multipart + response MUST inspect the Content-Range header field present in each + body part in order to determine which range is contained in that body + part; a client cannot rely on receiving the same ranges that it + requested, nor the same order that it requested. + + When a 206 response is generated, the server MUST generate the + following header fields, in addition to those required above, if the + field would have been sent in a 200 (OK) response to the same + request: Date, Cache-Control, ETag, Expires, Content-Location, and + Vary. + + If a 206 is generated in response to a request with an If-Range + header field, the sender SHOULD NOT generate other representation + header fields beyond those required above, because the client is + understood to already have a prior response containing those header + fields. Otherwise, the sender MUST generate all of the + representation header fields that would have been sent in a 200 (OK) + response to the same request. + + A 206 response is cacheable by default; i.e., unless otherwise + indicated by explicit cache controls (see Section 4.2.2 of + [RFC7234]). + +4.2. Content-Range + + The "Content-Range" header field is sent in a single part 206 + (Partial Content) response to indicate the partial range of the + selected representation enclosed as the message payload, sent in each + part of a multipart 206 response to indicate the range enclosed + within each body part, and sent in 416 (Range Not Satisfiable) + responses to provide information about the selected representation. + + Content-Range = byte-content-range + / other-content-range + + byte-content-range = bytes-unit SP + ( byte-range-resp / unsatisfied-range ) + + byte-range-resp = byte-range "/" ( complete-length / "*" ) + byte-range = first-byte-pos "-" last-byte-pos + unsatisfied-range = "*/" complete-length + + complete-length = 1*DIGIT + + other-content-range = other-range-unit SP other-range-resp + other-range-resp = *CHAR + + + +Fielding, et al. Standards Track [Page 12] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + If a 206 (Partial Content) response contains a Content-Range header + field with a range unit (Section 2) that 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. + + For byte ranges, a sender SHOULD indicate the complete length of the + representation from which the range has been extracted, unless the + complete length is unknown or difficult to determine. An asterisk + character ("*") in place of the complete-length indicates that the + representation length was unknown when the header field was + generated. + + The following example illustrates when the complete length of the + selected representation is known by the sender to be 1234 bytes: + + Content-Range: bytes 42-1233/1234 + + and this second example illustrates when the complete length is + unknown: + + Content-Range: bytes 42-1233/* + + A Content-Range field value is invalid if it contains a + byte-range-resp that has a last-byte-pos value less than its + first-byte-pos value, or a complete-length value less than or equal + to its last-byte-pos value. The recipient of an invalid + Content-Range MUST NOT attempt to recombine the received content with + a stored representation. + + A server generating a 416 (Range Not Satisfiable) response to a + byte-range request SHOULD send a Content-Range header field with an + unsatisfied-range value, as in the following example: + + Content-Range: bytes */1234 + + The complete-length in a 416 response indicates the current length of + the selected representation. + + The Content-Range header field has no meaning for status codes that + do not explicitly describe its semantic. For this specification, + only the 206 (Partial Content) and 416 (Range Not Satisfiable) status + codes describe a meaning for Content-Range. + + + + + + + + +Fielding, et al. Standards Track [Page 13] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + The following are examples of Content-Range values in which the + selected representation contains a total of 1234 bytes: + + o The first 500 bytes: + + Content-Range: bytes 0-499/1234 + + o The second 500 bytes: + + Content-Range: bytes 500-999/1234 + + o All except for the first 500 bytes: + + Content-Range: bytes 500-1233/1234 + + o The last 500 bytes: + + Content-Range: bytes 734-1233/1234 + +4.3. Combining Ranges + + A response might transfer only a subrange of a representation if the + connection closed prematurely or if the request used one or more + Range specifications. After several such transfers, a client might + have received several ranges of the same representation. These + ranges can only be safely combined if they all have in common the + same strong validator (Section 2.1 of [RFC7232]). + + A client that has received multiple partial responses to GET requests + on a target resource MAY combine those responses into a larger + continuous range if they share the same strong validator. + + If the most recent response is an incomplete 200 (OK) response, then + the header fields of that response are used for any combined response + and replace those of the matching stored responses. + + If the most recent response is a 206 (Partial Content) response and + at least one of the matching stored responses is a 200 (OK), then the + combined response header fields consist of the most recent 200 + response's header fields. If all of the matching stored responses + are 206 responses, then the stored response with the most recent + header fields is used as the source of header fields for the combined + response, except that the client MUST use other header fields + provided in the new response, aside from Content-Range, to replace + all instances of the corresponding header fields in the stored + response. + + + + + +Fielding, et al. Standards Track [Page 14] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + The combined response message body consists of the union of partial + content ranges in the new response and each of the selected + responses. If the union consists of the entire range of the + representation, then the client MUST process the combined response as + if it were a complete 200 (OK) response, including a Content-Length + header field that reflects the complete length. Otherwise, the + client MUST process the set of continuous ranges as one of the + following: an incomplete 200 (OK) response if the combined response + is a prefix of the representation, a single 206 (Partial Content) + response containing a multipart/byteranges body, or multiple 206 + (Partial Content) responses, each with one continuous range that is + indicated by a Content-Range header field. + +4.4. 416 Range Not Satisfiable + + The 416 (Range Not Satisfiable) status code indicates that none of + the ranges in the request's Range header field (Section 3.1) overlap + the current extent of the selected resource or that the set of ranges + requested has been rejected due to invalid ranges or an excessive + request of small or overlapping ranges. + + For byte ranges, failing to overlap the current extent means that the + first-byte-pos of all of the byte-range-spec values were greater than + the current length of the selected representation. When this status + code is generated in response to a byte-range request, the sender + SHOULD generate a Content-Range header field specifying the current + length of the selected representation (Section 4.2). + + For example: + + HTTP/1.1 416 Range Not Satisfiable + Date: Fri, 20 Jan 2012 15:41:54 GMT + Content-Range: bytes */47022 + + Note: Because servers are free to ignore Range, many + implementations will simply respond with the entire selected + representation in a 200 (OK) response. That is partly because + most clients are prepared to receive a 200 (OK) to complete the + task (albeit less efficiently) and partly because clients might + not stop making an invalid partial request until they have + received a complete representation. Thus, clients cannot depend + on receiving a 416 (Range Not Satisfiable) response even when it + is most appropriate. + + + + + + + + +Fielding, et al. Standards Track [Page 15] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +5. IANA Considerations + +5.1. Range Unit Registry + + The "HTTP Range Unit Registry" defines the namespace for the range + unit names and refers to their corresponding specifications. The + registry has been created and is now maintained at + . + +5.1.1. Procedure + + Registration of an HTTP Range Unit MUST include the following fields: + + o Name + + o Description + + o Pointer to specification text + + Values to be added to this namespace require IETF Review (see + [RFC5226], Section 4.1). + +5.1.2. Registrations + + The initial range unit registry contains the registrations below: + + +-------------+---------------------------------------+-------------+ + | Range Unit | Description | Reference | + | Name | | | + +-------------+---------------------------------------+-------------+ + | bytes | a range of octets | Section 2.1 | + | none | reserved as keyword, indicating no | Section 2.3 | + | | ranges are supported | | + +-------------+---------------------------------------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 16] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +5.2. Status Code Registration + + The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located + at has been + updated to include the registrations below: + + +-------+-----------------------+-------------+ + | Value | Description | Reference | + +-------+-----------------------+-------------+ + | 206 | Partial Content | Section 4.1 | + | 416 | Range Not Satisfiable | Section 4.4 | + +-------+-----------------------+-------------+ + +5.3. Header Field Registration + + HTTP header fields are registered within the "Message Headers" + registry maintained at + . + + This document defines the following HTTP header fields, so their + associated registry entries have been updated according to the + permanent registrations below (see [BCP90]): + + +-------------------+----------+----------+-------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+-------------+ + | Accept-Ranges | http | standard | Section 2.3 | + | Content-Range | http | standard | Section 4.2 | + | If-Range | http | standard | Section 3.2 | + | Range | http | standard | Section 3.1 | + +-------------------+----------+----------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + +5.4. Internet Media Type Registration + + IANA maintains the registry of Internet media types [BCP13] at + . + + This document serves as the specification for the Internet media type + "multipart/byteranges". The following has been registered with IANA. + + + + + + + + + +Fielding, et al. Standards Track [Page 17] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +5.4.1. Internet Media Type multipart/byteranges + + Type name: multipart + + Subtype name: byteranges + + Required parameters: boundary + + Optional parameters: N/A + + Encoding considerations: only "7bit", "8bit", or "binary" are + permitted + + Security considerations: see Section 6 + + Interoperability considerations: N/A + + Published specification: This specification (see Appendix A). + + Applications that use this media type: HTTP components supporting + multiple ranges in a single request. + + Fragment identifier considerations: N/A + + Additional information: + + Deprecated alias names for this type: N/A + + Magic number(s): N/A + + File extension(s): N/A + + Macintosh file type code(s): N/A + + Person and email address to contact for further information: See + Authors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See Authors' Addresses section. + + Change controller: IESG + + + + + + + +Fielding, et al. Standards Track [Page 18] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +6. Security Considerations + + This section is meant to inform developers, information providers, + and users of known security concerns specific to the HTTP range + request mechanisms. More general security considerations are + addressed in HTTP messaging [RFC7230] and semantics [RFC7231]. + +6.1. Denial-of-Service Attacks Using Range + + Unconstrained multiple range requests are susceptible to denial-of- + service attacks because the effort required to request many + overlapping ranges of the same data is tiny compared to the time, + memory, and bandwidth consumed by attempting to serve the requested + data in many parts. Servers ought to ignore, coalesce, or reject + egregious range requests, such as requests for more than two + overlapping ranges or for many small ranges in a single set, + particularly when the ranges are requested out of order for no + apparent reason. Multipart range requests are not designed to + support random access. + +7. Acknowledgments + + See Section 10 of [RFC7230]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 19] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +8. References + +8.1. Normative References + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + June 2014. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + June 2014. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, June 2014. + +8.2. Informative References + + [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, January 2013. + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + + + +Fielding, et al. Standards Track [Page 20] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Appendix A. Internet Media Type multipart/byteranges + + When a 206 (Partial Content) response message includes the content of + multiple ranges, they are transmitted as body parts in a multipart + message body ([RFC2046], Section 5.1) with the media type of + "multipart/byteranges". + + The multipart/byteranges media type includes one or more body parts, + each with its own Content-Type and Content-Range fields. The + required boundary parameter specifies the boundary string used to + separate each body part. + + Implementation Notes: + + 1. Additional CRLFs might precede the first boundary string in the + body. + + 2. Although [RFC2046] permits the boundary string to be quoted, some + existing implementations handle a quoted boundary string + incorrectly. + + 3. A number of clients and servers were coded to an early draft of + the byteranges specification that used a media type of multipart/ + x-byteranges, which is almost (but not quite) compatible with + this type. + + Despite the name, the "multipart/byteranges" media type is not + limited to byte ranges. The following example uses an "exampleunit" + range unit: + + HTTP/1.1 206 Partial Content + Date: Tue, 14 Nov 1995 06:25:24 GMT + Last-Modified: Tue, 14 July 04:58:08 GMT + Content-Length: 2331785 + Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES + + --THIS_STRING_SEPARATES + Content-Type: video/example + Content-Range: exampleunit 1.2-4.3/25 + + ...the first range... + --THIS_STRING_SEPARATES + Content-Type: video/example + Content-Range: exampleunit 11.2-14.3/25 + + ...the second range + --THIS_STRING_SEPARATES-- + + + + +Fielding, et al. Standards Track [Page 21] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Appendix B. Changes from RFC 2616 + + Servers are given more leeway in how they respond to a range request, + in order to mitigate abuse by malicious (or just greedy) clients. + (Section 3.1) + + A weak validator cannot be used in a 206 response. (Section 4.1) + + The Content-Range header field only has meaning when the status code + explicitly defines its use. (Section 4.2) + + This specification introduces a Range Unit Registry. (Section 5.1) + + multipart/byteranges can consist of a single part. (Appendix A) + +Appendix C. Imported ABNF + + The following core rules are included by reference, as defined in + Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), + CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double + quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any + 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII + character). + + Note that all rules derived from token are to be compared + case-insensitively, like range-unit and acceptable-ranges. + + The rules below are defined in [RFC7230]: + + OWS = + token = + + The rules below are defined in other parts: + + HTTP-date = + entity-tag = + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 22] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Appendix D. Collected ABNF + + In the collected ABNF below, list rules are expanded as per Section + 1.2 of [RFC7230]. + + Accept-Ranges = acceptable-ranges + + Content-Range = byte-content-range / other-content-range + + HTTP-date = + + If-Range = entity-tag / HTTP-date + + OWS = + + Range = byte-ranges-specifier / other-ranges-specifier + + acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS + range-unit ] ) ) / "none" + + byte-content-range = bytes-unit SP ( byte-range-resp / + unsatisfied-range ) + byte-range = first-byte-pos "-" last-byte-pos + byte-range-resp = byte-range "/" ( complete-length / "*" ) + byte-range-set = *( "," OWS ) ( byte-range-spec / + suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / + suffix-byte-range-spec ) ] ) + byte-range-spec = first-byte-pos "-" [ last-byte-pos ] + byte-ranges-specifier = bytes-unit "=" byte-range-set + bytes-unit = "bytes" + + complete-length = 1*DIGIT + + entity-tag = + + first-byte-pos = 1*DIGIT + + last-byte-pos = 1*DIGIT + + other-content-range = other-range-unit SP other-range-resp + other-range-resp = *CHAR + other-range-set = 1*VCHAR + other-range-unit = token + other-ranges-specifier = other-range-unit "=" other-range-set + + range-unit = bytes-unit / other-range-unit + + suffix-byte-range-spec = "-" suffix-length + + + +Fielding, et al. Standards Track [Page 23] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + suffix-length = 1*DIGIT + + token = + + unsatisfied-range = "*/" complete-length + +Index + + 2 + 206 Partial Content (status code) 10 + + 4 + 416 Range Not Satisfiable (status code) 15 + + A + Accept-Ranges header field 7 + + C + Content-Range header field 12 + + G + Grammar + Accept-Ranges 7 + acceptable-ranges 7 + byte-content-range 12 + byte-range 12 + byte-range-resp 12 + byte-range-set 5 + byte-range-spec 5 + byte-ranges-specifier 5 + bytes-unit 5 + complete-length 12 + Content-Range 12 + first-byte-pos 5 + If-Range 9 + last-byte-pos 5 + other-content-range 12 + other-range-resp 12 + other-range-unit 5, 7 + Range 8 + range-unit 5 + ranges-specifier 5 + suffix-byte-range-spec 6 + suffix-length 6 + unsatisfied-range 12 + + + + + + +Fielding, et al. Standards Track [Page 24] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + I + If-Range header field 9 + + M + Media Type + multipart/byteranges 18, 21 + multipart/x-byteranges 19 + multipart/byteranges Media Type 18, 21 + multipart/x-byteranges Media Type 21 + + R + Range header field 8 + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe Systems Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + Yves Lafon (editor) + World Wide Web Consortium + W3C / ERCIM + 2004, rte des Lucioles + Sophia-Antipolis, AM 06902 + France + + EMail: ylafon@w3.org + URI: http://www.raubacapeu.net/people/yves/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + +Fielding, et al. Standards Track [Page 25] + -- cgit v1.2.3