diff options
Diffstat (limited to 'vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt | 1512 |
1 files changed, 0 insertions, 1512 deletions
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt deleted file mode 100644 index 1ef7b0946..000000000 --- a/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt +++ /dev/null @@ -1,1512 +0,0 @@ - - - -HTTPbis Working Group R. Fielding, Ed. -Internet-Draft Day Software -Obsoletes: 2616 (if approved) J. Gettys -Intended status: Standards Track Alcatel-Lucent -Expires: February 5, 2011 J. Mogul - HP - H. Frystyk - Microsoft - L. Masinter - Adobe Systems - P. Leach - Microsoft - T. Berners-Lee - W3C/MIT - Y. Lafon, Ed. - W3C - J. Reschke, Ed. - greenbytes - August 4, 2010 - - - HTTP/1.1, part 5: Range Requests and Partial Responses - draft-ietf-httpbis-p5-range-11 - -Abstract - - The Hypertext Transfer Protocol (HTTP) is an application-level - protocol for distributed, collaborative, hypermedia information - systems. HTTP has been in use by the World Wide Web global - information initiative since 1990. This document is Part 5 of the - seven-part specification that defines the protocol referred to as - "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines - range-specific requests and the rules for constructing and combining - responses to those requests. - -Editorial Note (To be removed by RFC Editor) - - Discussion of this draft should take place on the HTTPBIS working - group mailing list (ietf-http-wg@w3.org). The current issues list is - at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related - documents (including fancy diffs) can be found at - <http://tools.ietf.org/wg/httpbis/>. - - The changes in this draft are summarized in Appendix D.12. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - - - -Fielding, et al. Expires February 5, 2011 [Page 1] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on February 5, 2011. - -Copyright Notice - - Copyright (c) 2010 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. Expires February 5, 2011 [Page 2] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 - 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 - 1.2.2. ABNF Rules defined in other Parts of the - Specification . . . . . . . . . . . . . . . . . . . . 6 - 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 - 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 - 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 - 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 - 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 - 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 - 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 - 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 - 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 - 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 - 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 - Appendix B. Compatibility with Previous Versions . . . . . . . . 20 - B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 - Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 - Appendix D. Change Log (to be removed by RFC Editor before - publication) . . . . . . . . . . . . . . . . . . . . 21 - D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 - D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21 - D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 - D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 - D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22 - D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22 - D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22 - D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 - D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23 - D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23 - D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23 - D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23 - - - -Fielding, et al. Expires February 5, 2011 [Page 3] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Fielding, et al. Expires February 5, 2011 [Page 4] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - -1. Introduction - - HTTP clients often encounter interrupted data transfers as a result - of cancelled requests or dropped connections. When a cache 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. There are also a number of Web - applications that benefit from being able to request only a subset of - a larger representation, such as a single page of a very large - document or only part of an image to be rendered by a device with - limited local storage. - - This document defines HTTP/1.1 range requests, partial responses, and - the multipart/byteranges media type. The protocol for range requests - is an OPTIONAL feature of HTTP, designed so resources or recipients - that do not implement this feature 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 intermediate caches that might not implement the - feature. - - Although the HTTP range request mechanism is designed to allow for - extensible range types, this specification only defines requests for - byte ranges. - -1.1. Requirements - - 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]. - - An implementation is not compliant if it fails to satisfy one or more - of the "MUST" or "REQUIRED" level requirements for the protocols it - implements. An implementation that satisfies all the "MUST" or - "REQUIRED" level and all the "SHOULD" level requirements for its - protocols is said to be "unconditionally compliant"; one that - satisfies all the "MUST" level requirements but not all the "SHOULD" - level requirements for its protocols is said to be "conditionally - compliant". - -1.2. Syntax Notation - - This specification uses the ABNF syntax defined in Section 1.2 of - [Part1] (which extends the syntax defined in [RFC5234] with a list - rule). Appendix C shows the collected ABNF, with the list rule - expanded. - - The following core rules are included by reference, as defined in - - - -Fielding, et al. Expires February 5, 2011 [Page 5] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - [RFC5234], Appendix B.1: 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), VCHAR (any visible USASCII character), - and WSP (whitespace). - -1.2.1. Core Rules - - The core rules below are defined in Section 1.2.2 of [Part1]: - - token = <token, defined in [Part1], Section 1.2.2> - OWS = <OWS, defined in [Part1], Section 1.2.2> - -1.2.2. ABNF Rules defined in other Parts of the Specification - - The ABNF rules below are defined in other parts: - - HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> - - - entity-tag = <entity-tag, defined in [Part4], Section 2> - -2. Range Units - - HTTP/1.1 allows a client to request that only part (a range of) the - representation be included within the response. HTTP/1.1 uses range - units in the Range (Section 5.4) and Content-Range (Section 5.2) - header fields. A representation can be broken down into subranges - according to various structural units. - - range-unit = bytes-unit / other-range-unit - bytes-unit = "bytes" - other-range-unit = token - - HTTP/1.1 has been designed to allow implementations of applications - that do not depend on knowledge of ranges. The only range unit - defined by HTTP/1.1 is "bytes". Additional specifiers can be defined - as described in Section 2.1. - - If a range unit is not understood in a request, a server MUST ignore - the whole Range header (Section 5.4). If a range unit is not - understood in a response, an intermediary SHOULD pass the response to - the client; a client MUST fail. - -2.1. Range Specifier Registry - - The HTTP Ranger Specifier Registry defines the name space for the - range specifier names. - - - -Fielding, et al. Expires February 5, 2011 [Page 6] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - Registrations MUST include the following fields: - - o Name - - o Description - - o Pointer to specification text - - Values to be added to this name space are subject to IETF review - ([RFC5226], Section 4.1). - - The registry itself is maintained at - <http://www.iana.org/assignments/http-range-specifiers>. - -3. Status Code Definitions - -3.1. 206 Partial Content - - The server has fulfilled the partial GET request for the resource. - The request MUST have included a Range header field (Section 5.4) - indicating the desired range, and MAY have included an If-Range - header field (Section 5.3) to make the request conditional. - - The response MUST include the following header fields: - - o Either a Content-Range header field (Section 5.2) indicating the - range included with this response, or a multipart/byteranges - Content-Type including Content-Range fields for each part. If a - Content-Length header field is present in the response, its value - MUST match the actual number of octets transmitted in the message- - body. - - o Date - - o Cache-Control, ETag, Expires, Content-Location, Last-Modified, - and/or Vary, if the header field would have been sent in a 200 - response to the same request - - If the 206 response is the result of an If-Range request, the - response SHOULD NOT include other representation header fields. - Otherwise, the response MUST include all of the representation header - fields that would have been returned with a 200 (OK) response to the - same request. - - A cache MUST NOT combine a 206 response with other previously cached - content if the ETag or Last-Modified headers do not match exactly, - see Section 4. - - - - -Fielding, et al. Expires February 5, 2011 [Page 7] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - A cache that does not support the Range and Content-Range headers - MUST NOT cache 206 (Partial Content) responses. Furthermore, if a - response uses a range unit that is not understood by the cache, then - it MUST NOT be cached either. - -3.2. 416 Requested Range Not Satisfiable - - A server SHOULD return a response with this status code if a request - included a Range request-header field (Section 5.4), and none of the - ranges-specifier values in this field overlap the current extent of - the selected resource, and the request did not include an If-Range - request-header field (Section 5.3). (For byte-ranges, this means - that the first-byte-pos of all of the byte-range-spec values were - greater than the current length of the selected resource.) - - When this status code is returned for a byte-range request, the - response SHOULD include a Content-Range header field specifying the - current length of the representation (see Section 5.2). This - response MUST NOT use the multipart/byteranges content-type. - -4. Combining Ranges - - A response might transfer only a subrange of a representation, either - because the request included one or more Range specifications, or - because a connection closed prematurely. After several such - transfers, a cache might have received several ranges of the same - representation. - - If a cache has a stored non-empty set of subranges for a - representation, and an incoming response transfers another subrange, - the cache MAY combine the new subrange with the existing set if both - the following conditions are met: - - o Both the incoming response and the cache entry have a cache - validator. - - o The two cache validators match using the strong comparison - function (see Section 4 of [Part4]). - - If either requirement is not met, the cache MUST use only the most - recent partial response (based on the Date values transmitted with - every response, and using the incoming response if these values are - equal or missing), and MUST discard the other partial information. - -5. Header Field Definitions - - This section defines the syntax and semantics of HTTP/1.1 header - fields related to range requests and partial responses. - - - -Fielding, et al. Expires February 5, 2011 [Page 8] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - -5.1. Accept-Ranges - - The "Accept-Ranges" response-header field allows a resource to - indicate its acceptance of range requests. - - Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v - Accept-Ranges-v = acceptable-ranges - acceptable-ranges = 1#range-unit / "none" - - Origin servers that accept byte-range requests MAY send - - Accept-Ranges: bytes - - but are not required to do so. Clients MAY generate range requests - without having received this header for the resource involved. Range - units are defined in Section 2. - - Servers that do not accept any kind of range request for a resource - MAY send - - Accept-Ranges: none - - to advise the client not to attempt a range request. - -5.2. Content-Range - - The "Content-Range" header field is sent with a partial - representation to specify where in the full representation the - payload body is intended to be applied. - - Range units are defined in Section 2. - - Content-Range = "Content-Range" ":" OWS Content-Range-v - Content-Range-v = content-range-spec - - content-range-spec = byte-content-range-spec - / other-content-range-spec - byte-content-range-spec = bytes-unit SP - byte-range-resp-spec "/" - ( instance-length / "*" ) - - byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) - / "*" - - instance-length = 1*DIGIT - - other-content-range-spec = other-range-unit SP - other-range-resp-spec - - - -Fielding, et al. Expires February 5, 2011 [Page 9] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - other-range-resp-spec = *CHAR - - The header SHOULD indicate the total length of the full - representation, unless this length is unknown or difficult to - determine. The asterisk "*" character means that the instance-length - is unknown at the time when the response was generated. - - Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- - range-resp-spec MUST only specify one range, and MUST contain - absolute byte positions for both the first and last byte of the - range. - - A byte-content-range-spec with a byte-range-resp-spec whose last- - byte-pos value is less than its first-byte-pos value, or whose - instance-length value is less than or equal to its last-byte-pos - value, is invalid. The recipient of an invalid byte-content-range- - spec MUST ignore it and any content transferred along with it. - - In the case of a byte range request: A server sending a response with - status code 416 (Requested range not satisfiable) SHOULD include a - Content-Range field with a byte-range-resp-spec of "*". The - instance-length specifies the current length of the selected - resource. A response with status code 206 (Partial Content) MUST NOT - include a Content-Range field with a byte-range-resp-spec of "*". - - Examples of byte-content-range-spec values, assuming that the - representation contains a total of 1234 bytes: - - o The first 500 bytes: - - bytes 0-499/1234 - - o The second 500 bytes: - - bytes 500-999/1234 - - o All except for the first 500 bytes: - - bytes 500-1233/1234 - - o The last 500 bytes: - - bytes 734-1233/1234 - - When an HTTP message includes the content of a single range (for - example, a response to a request for a single range, or to a request - for a set of ranges that overlap without any holes), this content is - transmitted with a Content-Range header, and a Content-Length header - - - -Fielding, et al. Expires February 5, 2011 [Page 10] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - showing the number of bytes actually transferred. 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 - - When an HTTP message includes the content of multiple ranges (for - example, a response to a request for multiple non-overlapping - ranges), these are transmitted as a multipart message. The multipart - media type used for this purpose is "multipart/byteranges" as defined - in Appendix A. - - A response to a request for a single range MUST NOT be sent using the - multipart/byteranges media type. A response to a request for - multiple ranges, whose result is a single range, MAY be sent as a - multipart/byteranges media type with one part. A client that cannot - decode a multipart/byteranges message MUST NOT ask for multiple - ranges in a single request. - - When a client requests multiple ranges in one request, the server - SHOULD return them in the order that they appeared in the request. - - If the server ignores a byte-range-spec because it is syntactically - invalid, the server SHOULD treat the request as if the invalid Range - header field did not exist. (Normally, this means return a 200 - response containing the full representation). - - If the server receives a request (other than one including an If- - Range request-header field) with an unsatisfiable Range request- - header field (that is, all of whose byte-range-spec values have a - first-byte-pos value greater than the current length of the selected - resource), it SHOULD return a response code of 416 (Requested range - not satisfiable) (Section 3.2). - - Note: Clients cannot depend on servers to send a 416 (Requested - range not satisfiable) response instead of a 200 (OK) response for - an unsatisfiable Range request-header, since not all servers - implement this request-header. - -5.3. If-Range - - If a client has a partial copy of a representation in its cache, and - wishes to have an up-to-date copy of the entire representation in its - cache, it could use the Range request-header with a conditional GET - (using either or both of If-Unmodified-Since and If-Match.) However, - - - -Fielding, et al. Expires February 5, 2011 [Page 11] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - if the condition 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" request-header field allows a client to "short- - circuit" the second request. Informally, its meaning is "if the - representation is unchanged, send me the part(s) that I am missing; - otherwise, send me the entire new representation". - - If-Range = "If-Range" ":" OWS If-Range-v - If-Range-v = entity-tag / HTTP-date - - If the client has no entity-tag for a representation, but does have a - Last-Modified date, it MAY use that date in an If-Range header. (The - server can distinguish between a valid HTTP-date and any form of - entity-tag by examining no more than two characters.) The If-Range - header SHOULD only be used together with a Range header, and MUST be - ignored if the request does not include a Range header, or if the - server does not support the sub-range operation. - - If the entity-tag given in the If-Range header matches the current - cache validator for the representation, then the server SHOULD - provide the specified sub-range of the representation using a 206 - (Partial Content) response. If the cache validator does not match, - then the server SHOULD return the entire representation using a 200 - (OK) response. - -5.4. Range - -5.4.1. Byte Ranges - - Since all HTTP representations are transferred as sequences of bytes, - the concept of a byte range is meaningful for any HTTP - representation. (However, not all clients and servers need to - support byte-range operations.) - - Byte range specifications in HTTP apply to the sequence of bytes in - the representation body (not necessarily the same as the message- - body). - - A byte range operation MAY 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 - - - -Fielding, et al. Expires February 5, 2011 [Page 12] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - 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. - - If the last-byte-pos value is present, it MUST be greater than or - equal to the first-byte-pos in that byte-range-spec, or the byte- - range-spec is syntactically invalid. The recipient of a byte-range- - set that includes one or more syntactically invalid byte-range-spec - values MUST ignore the header field that includes that byte-range- - set. - - If the last-byte-pos value is absent, or if the value is greater than - or equal to the current length of the representation body, last-byte- - pos is taken to be equal to one less than the current length of the - representation in bytes. - - By its choice of last-byte-pos, a client can limit the number of - bytes retrieved without knowing the size of the representation. - - suffix-byte-range-spec = "-" suffix-length - suffix-length = 1*DIGIT - - A suffix-byte-range-spec is used to specify the suffix of the - representation body, of a length given by the suffix-length value. - (That is, this form specifies the last N bytes of a representation.) - If the representation is shorter than the specified suffix-length, - the entire representation is used. - - If a syntactically valid byte-range-set includes at least one byte- - range-spec whose first-byte-pos 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. If the byte-range- - set is unsatisfiable, the server SHOULD return a response with a 416 - (Requested range not satisfiable) status code. Otherwise, the server - SHOULD return a response with a 206 (Partial Content) status code - containing the satisfiable ranges of the representation. - - Examples of byte-ranges-specifier values (assuming a representation - of length 10000): - - o The first 500 bytes (byte offsets 0-499, inclusive): - - bytes=0-499 - - - - - - -Fielding, et al. Expires February 5, 2011 [Page 13] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - o The second 500 bytes (byte offsets 500-999, inclusive): - - bytes=500-999 - - 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 Several legal but not canonical specifications of the second 500 - bytes (byte offsets 500-999, inclusive): - - bytes=500-600,601-999 - bytes=500-700,601-999 - -5.4.2. Range Retrieval Requests - - The "Range" request-header field defines the GET method (conditional - or not) to request one or more sub-ranges of the response - representation body, instead of the entire representation body. - - Range = "Range" ":" OWS Range-v - Range-v = byte-ranges-specifier - / other-ranges-specifier - other-ranges-specifier = other-range-unit "=" other-range-set - other-range-set = 1*CHAR - - A server MAY ignore the Range header. However, HTTP/1.1 origin - servers and intermediate caches ought to support byte ranges when - possible, since Range supports efficient recovery from partially - failed transfers, and supports efficient partial retrieval of large - representations. - - If the server supports the Range header and the specified range or - ranges are appropriate for the representation: - - o The presence of a Range header in an unconditional GET modifies - what is returned if the GET is otherwise successful. In other - words, the response carries a status code of 206 (Partial Content) - instead of 200 (OK). - - - - -Fielding, et al. Expires February 5, 2011 [Page 14] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - o The presence of a Range header in a conditional GET (a request - using one or both of If-Modified-Since and If-None-Match, or one - or both of If-Unmodified-Since and If-Match) modifies what is - returned if the GET is otherwise successful and the condition is - true. It does not affect the 304 (Not Modified) response returned - if the conditional is false. - - In some cases, it might be more appropriate to use the If-Range - header (see Section 5.3) in addition to the Range header. - - If a proxy that supports ranges receives a Range request, forwards - the request to an inbound server, and receives an entire - representation in reply, it SHOULD only return the requested range to - its client. It SHOULD store the entire received response in its - cache if that is consistent with its cache allocation policies. - -6. IANA Considerations - -6.1. Status Code Registration - - The HTTP Status Code Registry located at - <http://www.iana.org/assignments/http-status-codes> shall be updated - with the registrations below: - - +-------+---------------------------------+-------------+ - | Value | Description | Reference | - +-------+---------------------------------+-------------+ - | 206 | Partial Content | Section 3.1 | - | 416 | Requested Range Not Satisfiable | Section 3.2 | - +-------+---------------------------------+-------------+ - -6.2. Header Field Registration - - The Message Header Field Registry located at <http://www.iana.org/ - assignments/message-headers/message-header-index.html> shall be - updated with the permanent registrations below (see [RFC3864]): - - +-------------------+----------+----------+-------------+ - | Header Field Name | Protocol | Status | Reference | - +-------------------+----------+----------+-------------+ - | Accept-Ranges | http | standard | Section 5.1 | - | Content-Range | http | standard | Section 5.2 | - | If-Range | http | standard | Section 5.3 | - | Range | http | standard | Section 5.4 | - +-------------------+----------+----------+-------------+ - - The change controller is: "IETF (iesg@ietf.org) - Internet - Engineering Task Force". - - - -Fielding, et al. Expires February 5, 2011 [Page 15] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - -6.3. Range Specifier Registration - - The registration procedure for HTTP Range Specifiers is defined by - Section 2.1 of this document. - - The HTTP Range Specifier Registry shall be created at - <http://www.iana.org/assignments/http-range-specifiers> and be - populated with the registrations below: - - +----------------------+-------------------+----------------------+ - | Range Specifier Name | Description | Reference | - +----------------------+-------------------+----------------------+ - | bytes | a range of octets | (this specification) | - +----------------------+-------------------+----------------------+ - - The change controller is: "IETF (iesg@ietf.org) - Internet - Engineering Task Force". - -7. Security Considerations - - No additional security considerations have been identified beyond - those applicable to HTTP in general [Part1]. - -8. Acknowledgments - - Most of the specification of ranges is based on work originally done - by Ari Luotonen and John Franks, with additional input from Steve - Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin - Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, - Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi - Rizzo, and Bill Weihl. - -9. References - -9.1. Normative References - - [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., - and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, - and Message Parsing", draft-ietf-httpbis-p1-messaging-11 - (work in progress), August 2010. - - [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., - and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional - Requests", draft-ietf-httpbis-p4-conditional-11 (work in - progress), August 2010. - - - - -Fielding, et al. Expires February 5, 2011 [Page 16] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - [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. - -9.2. Informative References - - [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. - - [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration - Procedures for Message Header Fields", BCP 90, RFC 3864, - September 2004. - - [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and - Registration Procedures", BCP 13, RFC 4288, December 2005. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, - May 2008. - -Appendix A. Internet Media Type multipart/byteranges - - When an HTTP 206 (Partial Content) response message includes the - content of multiple ranges (a response to a request for multiple non- - overlapping ranges), these are transmitted as a multipart message- - body ([RFC2046], Section 5.1). The media type for this purpose is - called "multipart/byteranges". The following is to be registered - with IANA [RFC4288]. - - Note: Despite the name "multipart/byteranges" is not limited to - the byte ranges only. - - The multipart/byteranges media type includes one or more 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. - - - - - - - - -Fielding, et al. Expires February 5, 2011 [Page 17] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - Type name: multipart - - Subtype name: byteranges - - Required parameters: boundary - - Optional parameters: none - - Encoding considerations: only "7bit", "8bit", or "binary" are - permitted - - Security considerations: none - - Interoperability considerations: none - - Published specification: This specification (see Appendix A). - - Applications that use this media type: - - Additional information: - - Magic number(s): none - - File extension(s): none - - Macintosh file type code(s): none - - Person and email address to contact for further information: See - Authors Section. - - Intended usage: COMMON - - Restrictions on usage: none - - Author/Change controller: IESG - - - - - - - - - - - - - - - - -Fielding, et al. Expires February 5, 2011 [Page 18] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - 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-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-- - - Other example: - - 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-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-- - - Notes: - - 1. Additional CRLFs MAY 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. - - - - - -Fielding, et al. Expires February 5, 2011 [Page 19] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - 3. A number of browsers and servers were coded to an early draft of - the byteranges specification to use a media type of multipart/ - x-byteranges, which is almost, but not quite compatible with the - version documented in HTTP/1.1. - -Appendix B. Compatibility with Previous Versions - -B.1. Changes from RFC 2616 - - Clarify that it is not ok to use a weak cache validator in a 206 - response. (Section 3.1) - - Clarify that multipart/byteranges can consist of a single part. - (Appendix A) - -Appendix C. Collected ABNF - - Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v - Accept-Ranges-v = acceptable-ranges - - Content-Range = "Content-Range:" OWS Content-Range-v - Content-Range-v = content-range-spec - - HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> - - If-Range = "If-Range:" OWS If-Range-v - If-Range-v = entity-tag / HTTP-date - - OWS = <OWS, defined in [Part1], Section 1.2.2> - - Range = "Range:" OWS Range-v - Range-v = byte-ranges-specifier / other-ranges-specifier - - acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS - range-unit ] ) ) / "none" - - byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( - instance-length / "*" ) - byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" - 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" - - content-range-spec = byte-content-range-spec / - other-content-range-spec - - - -Fielding, et al. Expires February 5, 2011 [Page 20] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - entity-tag = <entity-tag, defined in [Part4], Section 2> - - first-byte-pos = 1*DIGIT - - instance-length = 1*DIGIT - - last-byte-pos = 1*DIGIT - - other-content-range-spec = other-range-unit SP other-range-resp-spec - other-range-resp-spec = *CHAR - other-range-set = 1*CHAR - 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 - suffix-length = 1*DIGIT - - token = <token, defined in [Part1], Section 1.2.2> - - ABNF diagnostics: - - ; Accept-Ranges defined but not used - ; Content-Range defined but not used - ; If-Range defined but not used - ; Range defined but not used - -Appendix D. Change Log (to be removed by RFC Editor before publication) - -D.1. Since RFC2616 - - Extracted relevant partitions from [RFC2616]. - -D.2. Since draft-ietf-httpbis-p5-range-00 - - Closed issues: - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache - validators in 206 responses" - (<http://purl.org/NET/http-errata#ifrange206>) - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and - Informative references" - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- - to-date references" - - - - -Fielding, et al. Expires February 5, 2011 [Page 21] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - -D.3. Since draft-ietf-httpbis-p5-range-01 - - Closed issues: - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to - RFC4288" - - Ongoing work on ABNF conversion - (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): - - o Add explicit references to BNF syntax and rules imported from - other parts of the specification. - -D.4. Since draft-ietf-httpbis-p5-range-02 - - Ongoing work on IANA Message Header Registration - (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): - - o Reference RFC 3984, and update header registrations for headers - defined in this document. - -D.5. Since draft-ietf-httpbis-p5-range-03 - -D.6. Since draft-ietf-httpbis-p5-range-04 - - Closed issues: - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/ - byteranges minimum number of parts" - - Ongoing work on ABNF conversion - (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): - - o Use "/" instead of "|" for alternatives. - - o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional - whitespace ("OWS") and required whitespace ("RWS"). - - o Rewrite ABNFs to spell out whitespace rules, factor out header - value format definitions. - -D.7. Since draft-ietf-httpbis-p5-range-05 - - Closed issues: - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base - for *-byte-pos and suffix-length" - - - - -Fielding, et al. Expires February 5, 2011 [Page 22] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - Ongoing work on Custom Ranges - (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>): - - o Remove bias in favor of byte ranges; allow custom ranges in ABNF. - - Final work on ABNF conversion - (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): - - o Add appendix containing collected and expanded ABNF, reorganize - ABNF introduction. - -D.8. Since draft-ietf-httpbis-p5-range-06 - - Closed issues: - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for - numeric protocol elements" - -D.9. Since draft-ietf-httpbis-p5-range-07 - - Closed issues: - - o Fixed discrepancy in the If-Range definition about allowed - validators. - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/150>: "multipart/ - byteranges for custom range units" - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/151>: "range unit - missing from other-ranges-specifier in Range header" - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA - registrations for optional status codes" - -D.10. Since draft-ietf-httpbis-p5-range-08 - - No significant changes. - -D.11. Since draft-ietf-httpbis-p5-range-09 - - No significant changes. - -D.12. Since draft-ietf-httpbis-p5-range-10 - - Closed issues: - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify - 'Requested Variant'" - - - -Fielding, et al. Expires February 5, 2011 [Page 23] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify - entity / representation / variant terminology" - - o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider - removing the 'changes from 2068' sections" - - Ongoing work on Custom Ranges - (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>): - - o Add IANA registry. - -Index - - 2 - 206 Partial Content (status code) 7 - - 4 - 416 Requested Range Not Satisfiable (status code) 8 - - A - Accept-Ranges header 9 - - C - Content-Range header 9 - - G - Grammar - Accept-Ranges 9 - Accept-Ranges-v 9 - acceptable-ranges 9 - byte-content-range-spec 9 - byte-range-resp-spec 9 - byte-range-set 12 - byte-range-spec 12 - byte-ranges-specifier 12 - bytes-unit 6 - Content-Range 9 - content-range-spec 9 - Content-Range-v 9 - first-byte-pos 12 - If-Range 12 - If-Range-v 12 - instance-length 9 - last-byte-pos 12 - other-range-unit 6 - Range 14 - range-unit 6 - ranges-specifier 12 - - - -Fielding, et al. Expires February 5, 2011 [Page 24] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - suffix-byte-range-spec 13 - suffix-length 13 - - H - Headers - Accept-Ranges 9 - Content-Range 9 - If-Range 11 - Range 12 - - I - If-Range header 11 - - M - Media Type - multipart/byteranges 17 - multipart/x-byteranges 20 - multipart/byteranges Media Type 17 - multipart/x-byteranges Media Type 20 - - R - Range header 12 - - S - Status Codes - 206 Partial Content 7 - 416 Requested Range Not Satisfiable 8 - -Authors' Addresses - - Roy T. Fielding (editor) - Day Software - 23 Corporate Plaza DR, Suite 280 - Newport Beach, CA 92660 - USA - - Phone: +1-949-706-5300 - Fax: +1-949-706-5305 - EMail: fielding@gbiv.com - URI: http://roy.gbiv.com/ - - - - - - - - - - - -Fielding, et al. Expires February 5, 2011 [Page 25] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - Jim Gettys - Alcatel-Lucent Bell Labs - 21 Oak Knoll Road - Carlisle, MA 01741 - USA - - EMail: jg@freedesktop.org - URI: http://gettys.wordpress.com/ - - - Jeffrey C. Mogul - Hewlett-Packard Company - HP Labs, Large Scale Systems Group - 1501 Page Mill Road, MS 1177 - Palo Alto, CA 94304 - USA - - EMail: JeffMogul@acm.org - - - Henrik Frystyk Nielsen - Microsoft Corporation - 1 Microsoft Way - Redmond, WA 98052 - USA - - EMail: henrikn@microsoft.com - - - Larry Masinter - Adobe Systems, Incorporated - 345 Park Ave - San Jose, CA 95110 - USA - - EMail: LMM@acm.org - URI: http://larry.masinter.net/ - - - Paul J. Leach - Microsoft Corporation - 1 Microsoft Way - Redmond, WA 98052 - - EMail: paulle@microsoft.com - - - - - - -Fielding, et al. Expires February 5, 2011 [Page 26] - -Internet-Draft HTTP/1.1, Part 5 August 2010 - - - Tim Berners-Lee - World Wide Web Consortium - MIT Computer Science and Artificial Intelligence Laboratory - The Stata Center, Building 32 - 32 Vassar Street - Cambridge, MA 02139 - USA - - EMail: timbl@w3.org - URI: http://www.w3.org/People/Berners-Lee/ - - - 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 - - Phone: +49 251 2807760 - Fax: +49 251 2807761 - EMail: julian.reschke@greenbytes.de - URI: http://greenbytes.de/tech/webdav/ - - - - - - - - - - - - - - - - - - -Fielding, et al. Expires February 5, 2011 [Page 27] - |