| draft-ietf-httpbis-p5-range-21.txt |  | draft-ietf-httpbis-p5-range-22.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) Y. Lafon, Ed. |  | Obsoletes: 2616 (if approved) Y. Lafon, Ed. |
| Intended status: Standards Track W3C |  | Intended status: Standards Track W3C |
| Expires: April 7, 2013 J. Reschke, Ed. |  | Expires: August 27, 2013 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| October 4, 2012 |  | February 23, 2013 |
| Hypertext Transfer Protocol (HTTP/1.1): Range Requests |  | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| draft-ietf-httpbis-p5-range-21 |  | draft-ietf-httpbis-p5-range-22 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext information |
| systems. This document defines range requests and the rules for |  | systems. This document defines range requests and the rules for |
| constructing and combining responses to those requests. |  | constructing and combining responses to those requests. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix E.2. |  | The changes in this draft are summarized in Appendix E.3. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on April 7, 2013. |  | This Internet-Draft will expire on August 27, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2013 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 3, line 11 |  | skipping to change at page 3, line 11 |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5 |  | 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 |
| 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 |  | 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 |  | 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7 |  | 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 4.1. Response to a Single and Multiple Ranges Request . . . . . 7 |  | 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 7 |  | 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 |  | 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 |
| 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8 |  | 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 |
| 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 |  | 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 |
| 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 |
| 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |
| 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 |  | 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 |
| 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 |  | 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 |  | 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 |
| 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 |  | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 |
| 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 |  | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 |
| 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 |  | 6.1. Denial of Service Attacks using Range . . . . . . . . . . 17 |
| 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 |  | Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 19 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 19 |  |  |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 22 |  | publication) . . . . . . . . . . . . . . . . . . . . 23 |
| E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22 |  | E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 |
| E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 22 |  | E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 |
| 1. Introduction |  | 1. Introduction |
| HTTP clients often encounter interrupted data transfers as a result |  | Hypertext Transfer Protocol (HTTP) clients often encounter |
| of canceled requests or dropped connections. When a client has |  | interrupted data transfers as a result of canceled requests or |
| stored a partial representation, it is desirable to request the |  | dropped connections. When a client has stored a partial |
| remainder of that representation in a subsequent request rather than |  | representation, it is desirable to request the remainder of that |
| transfer the entire representation. There are also a number of Web |  | representation in a subsequent request rather than transfer the |
| applications that benefit from being able to request only a subset of |  | entire representation. Likewise, devices with limited local storage |
| a larger representation, such as a single page of a very large |  | might benefit from being able to request only a subset of a larger |
| document or only part of an image to be rendered by a device with |  | representation, such as a single page of a very large document, or |
| limited local storage. |  | the dimensions of an embedded image. |
| This document defines HTTP/1.1 range requests, partial responses, and |  | This document defines HTTP/1.1 range requests, partial responses, and |
| the multipart/byteranges media type. The protocol for range requests |  | the multipart/byteranges media type, obsoleting those parts |
| is an OPTIONAL feature of HTTP, designed so resources or recipients |  | previously defined in [RFC2616]. Range requests are an OPTIONAL |
| that do not implement this feature can respond as if it is a normal |  | feature of HTTP, designed so that recipients not implementing this |
| GET request without impacting interoperability. Partial responses |  | feature (or not supporting it for the target resource) can respond as |
| are indicated by a distinct status code to not be mistaken for full |  | if it is a normal GET request without impacting interoperability. |
| responses by intermediate caches that might not implement the |  | Partial responses are indicated by a distinct status code to not be |
|  |  | mistaken for full responses by caches that might not implement the |
| feature. |  | feature. |
| Although the HTTP range request mechanism is designed to allow for |  | Although the range request mechanism is designed to allow for |
| extensible range types, this specification only defines requests for |  | extensible range types, this specification only defines requests for |
| byte ranges. |  | byte ranges. |
| 1.1. Conformance and Error Handling |  | 1.1. Conformance and Error Handling |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| Conformance criteria and considerations regarding error handling are |  | Conformance criteria and considerations regarding error handling are |
| skipping to change at page 4, line 49 |  | skipping to change at page 4, line 50 |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix C describes rules imported from other |  | 1.2 of [Part1]. Appendix C describes rules imported from other |
| documents. Appendix D shows the collected ABNF with the list rule |  | documents. Appendix D shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| 2. Range Units |  | 2. Range Units |
| HTTP/1.1 allows a client to request that only part (a range) of the |  | A representation can be partitioned into subranges according to |
| representation be included within the response. HTTP/1.1 uses range |  | various structural units, depending on the structure inherent in the |
| units in the Range (Section 5.4) and Content-Range (Section 5.2) |  | representation's media type. This "range unit" is used in the |
| header fields. A representation can be broken down into subranges |  | Accept-Ranges (Section 2.3) response header field to advertise |
| according to various structural units. |  | 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 |  | 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 field (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 Range Specifier Registry defines the name space for the |  |  |
| range specifier names. |  |  |
| Registrations MUST include the following fields: |  |  |
| o Name |  |  |
| o Description |  |  |
| o Pointer to specification text |  |  |
| Values to be added to this name space require IETF Review (see |  | 2.1. Byte Ranges |
| [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. |  | Since representation data is transferred in payloads as a sequence of |
| The request MUST have included a Range header field (Section 5.4) |  | octets, a byte range is a meaningful substructure for any |
| indicating the desired range, and MAY have included an If-Range |  | representation transferable over HTTP (Section 3 of [Part2]). We |
| header field (Section 5.3) to make the request conditional. |  | define the "bytes" range unit for expressing subranges of the data's |
|  |  | octet sequence. |
| The response MUST include the following header fields: |  | bytes-unit = "bytes" |
| o Either a Content-Range header field (Section 5.2) indicating the |  | A byte range operation MAY specify a single range of bytes, or a set |
| range included with this response, or a multipart/byteranges |  | of ranges within a single representation. |
| 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 |  | 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 |
| o Cache-Control, ETag, Expires, Content-Location and/or Vary, if the |  | The first-byte-pos value in a byte-range-spec gives the byte-offset |
| header field would have been sent in a 200 (OK) response to the |  | of the first byte in a range. The last-byte-pos value gives the |
| same request |  | byte-offset of the last byte in the range; that is, the byte |
|  |  | positions specified are inclusive. Byte offsets start at zero. |
| If a 206 is sent in response to a request with an If-Range header |  | Examples of byte-ranges-specifier values: |
| field, it 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. |  |  |
| Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |  | o The first 500 bytes (byte offsets 0-499, inclusive): |
| determine freshness for 206 responses. |  |  |
| 3.2. 416 Requested Range Not Satisfiable |  | bytes=0-499 |
| A server SHOULD return a response with this status code if a request |  | o The second 500 bytes (byte offsets 500-999, inclusive): |
| included a Range 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 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 |  | bytes=500-999 |
| 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. For |  |  |
| example, |  |  |
| HTTP/1.1 416 Requested Range Not Satisfiable |  | A byte-range-spec is invalid if the last-byte-pos value is present |
| Date: Mon, 20 Jan 2012 15:41:54 GMT |  | and less than the first-byte-pos. |
| Content-Range: bytes */47022 |  |  |
| Content-Type: image/gif |  |  |
| Note: Clients cannot depend on servers to send a 416 (Requested |  | A client can limit the number of bytes requested without knowing the |
| Range Not Satisfiable) response instead of a 200 (OK) response for |  | size of the selected representation. If the last-byte-pos value is |
| an unsatisfiable Range header field, since not all servers |  | absent, or if the value is greater than or equal to the current |
| implement this header field. |  | 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). |
| 4. Responses to a Range Request |  | A client can request the last N bytes of the selected representation |
|  |  | using a suffix-byte-range-spec. |
| 4.1. Response to a Single and Multiple Ranges Request |  | suffix-byte-range-spec = "-" suffix-length |
|  |  | suffix-length = 1*DIGIT |
| When an HTTP message includes the content of a single range (for |  | If the selected representation is shorter than the specified suffix- |
| example, a response to a request for a single range, or to a request |  | length, the entire representation is used. For example (assuming a |
| for a set of ranges that overlap without any holes), this content is |  | representation of length 10000): |
| transmitted with a Content-Range header field, and a Content-Length |  |  |
| header field showing the number of bytes actually transferred. For |  |  |
| example, |  |  |
| HTTP/1.1 206 Partial Content |  | o The final 500 bytes (byte offsets 9500-9999, inclusive): |
| 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 |  | bytes=-500 |
| 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 server MAY combine requested ranges when those ranges are |  | Or: |
| overlapping (see Section 7.1). |  |  |
| A response to a request for a single range MUST NOT be sent using the |  | bytes=9500- |
| 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 asks for multiple ranges in one request, the server |  | o The first and last bytes only (bytes 0 and 9999): |
| SHOULD return them in the order that they appeared in the request. |  |  |
| 4.2. Combining Ranges |  | bytes=0-0,-1 |
| A response might transfer only a subrange of a representation if the |  | o Other valid (but not canonical) specifications of the second 500 |
| connection closed prematurely or if the request used one or more |  | bytes (byte offsets 500-999, inclusive): |
| 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, where "strong validator" is defined to be |  |  |
| either an entity-tag that is not marked as weak (Section 2.3 of |  |  |
| [Part4]) or, if no entity-tag is provided, a Last-Modified value that |  |  |
| is strong in the sense defined by Section 2.2.2 of [Part4]. |  |  |
| When a client receives an incomplete 200 (OK) or 206 (Partial |  | bytes=500-600,601-999 |
| Content) response and already has one or more stored responses for |  | bytes=500-700,601-999 |
| the same method and effective request URI, all of the stored |  |  |
| responses with the same strong validator MAY be combined with the |  |  |
| partial content in this new response. If none of the stored |  |  |
| responses contain the same strong validator, then this new response |  |  |
| corresponds to a new representation and MUST NOT be combined with the |  |  |
| existing stored responses. |  |  |
| If the new response is an incomplete 200 (OK) response, then the |  | If a valid byte-range-set includes at least one byte-range-spec with |
| header fields of that new response are used for any combined response |  | a first-byte-pos that is less than the current length of the |
| and replace those of the matching stored responses. |  | 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 new response is a 206 (Partial Content) response and at least |  | In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- |
| one of the matching stored responses is a 200 (OK), then the combined |  | length are expressed as decimal number of octets. Since there is no |
| response header fields consist of the most recent 200 response's |  | predefined limit to the length of a payload, recipients ought to |
| header fields. If all of the matching stored responses are 206 |  | anticipate potentially large decimal numerals and prevent parsing |
| responses, then the stored response with the most header fields is |  | errors due to integer conversion overflows. |
| 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. |  |  |
| The combined response message body consists of the union of partial |  | 2.2. Other Range Units |
| 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 combined response MUST be recorded as a |  |  |
| complete 200 (OK) response with a Content-Length header field that |  |  |
| reflects the complete length. Otherwise, the combined response(s) |  |  |
| MUST include a Content-Range header field describing the included |  |  |
| range(s) and be recorded as incomplete. If the union consists of a |  |  |
| discontinuous range of the representation, then the client MAY store |  |  |
| it as either a multipart range response or as multiple 206 responses |  |  |
| with one continuous range each. |  |  |
| 5. Header Field Definitions |  | Range units are intended to be extensible. New range units ought to |
|  |  | be registered with IANA, as defined in Section 5.1. |
| This section defines the syntax and semantics of HTTP/1.1 header |  | other-range-unit = token |
| fields related to range requests and partial responses. |  |  |
| 5.1. Accept-Ranges |  | 2.3. Accept-Ranges |
| The "Accept-Ranges" header field allows a resource to indicate its |  | The "Accept-Ranges" header field allows a server to indicate that it |
| acceptance of range requests. |  | supports range requests for the target resource. |
| Accept-Ranges = acceptable-ranges |  | Accept-Ranges = acceptable-ranges |
| acceptable-ranges = 1#range-unit / "none" |  | acceptable-ranges = 1#range-unit / "none" |
| Origin servers that accept byte-range requests MAY send |  | Origin servers that support byte-range requests MAY send |
| Accept-Ranges: bytes |  | Accept-Ranges: bytes |
| but are not required to do so. Clients MAY generate range requests |  | but are not required to do so. Clients MAY generate range requests |
| without having received this header field for the resource involved. |  | without having received this header field for the resource involved. |
| Range units are defined in Section 2. |  | Range units are defined in Section 2. |
| Servers that do not accept any kind of range request for a resource |  | Servers that do not support any kind of range request for the target |
| MAY send |  | resource resource MAY send |
| Accept-Ranges: none |  | Accept-Ranges: none |
| to advise the client not to attempt a range request. |  | to advise the client not to attempt a range request. |
| 5.2. Content-Range |  | 3. Range Requests |
| 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 = 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 |  |  |
| other-range-resp-spec = *CHAR |  |  |
| The header field 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 "*". |  |  |
| The "Content-Range" header field has no meaning for status codes that |  | 3.1. Range |
| do not explicitly describe its semantic. Currently, only status |  |  |
| codes 206 (Partial Content) and 416 (Requested Range Not Satisfiable) |  |  |
| describe the meaning of this header field. |  |  |
| Examples of byte-content-range-spec values, assuming that the |  | The "Range" header field on a GET request modifies the method |
| representation contains a total of 1234 bytes: |  | semantics to request transfer of only one or more subranges of the |
|  |  | selected representation data, rather than the entire selected |
|  |  | representation data. |
| o The first 500 bytes: |  | Range = byte-ranges-specifier / other-ranges-specifier |
|  |  | other-ranges-specifier = other-range-unit "=" other-range-set |
|  |  | other-range-set = 1*CHAR |
| bytes 0-499/1234 |  | 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. |
| o The second 500 bytes: |  | An origin server MUST ignore a Range header field that contains a |
|  |  | range unit it does not understand. A proxy MAY either discard a |
|  |  | Range header field that contains a range unit it does not understand |
|  |  | or pass it to the next inbound server when forwarding the request. |
| bytes 500-999/1234 |  | A server that supports range requests ought to 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. |
| o All except for the first 500 bytes: |  | 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. |
| bytes 500-1233/1234 |  | The Range header field is evaluated after evaluating the |
|  |  | preconditions of [Part4] and only if the result of their evaluation |
|  |  | is leading toward a 200 (OK) response. In other words, Range is |
|  |  | ignored when a conditional GET would result in a 304 (Not Modified) |
|  |  | response. |
| o The last 500 bytes: |  | The If-Range header field (Section 3.2) can be used as a precondition |
|  |  | to applying the Range header field. |
| bytes 734-1233/1234 |  | 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 the server ignores a byte-range-spec (for example if it is |  | If all of the preconditions are true, the server supports the Range |
| syntactically invalid, or if it might be seen as a denial-of-service |  | header field for the target resource, and the specified range(s) are |
| attack), the server SHOULD treat the request as if the invalid Range |  | invalid or unsatisfiable, the server SHOULD send a 416 (Range Not |
| header field did not exist. (Normally, this means return a 200 (OK) |  | Satisfiable) response. |
| response containing the full representation). |  |  |
| 5.3. If-Range |  | 3.2. If-Range |
| If a client has a partial copy of a representation and wishes to have |  | 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 |  | 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 |  | Range header field with a conditional GET (using either or both of |
| If-Unmodified-Since and If-Match.) However, if the condition fails |  | If-Unmodified-Since and If-Match.) However, if the condition fails |
| because the representation has been modified, the client would then |  | because the representation has been modified, the client would then |
| have to make a second request to obtain the entire current |  | have to make a second request to obtain the entire current |
| representation. |  | representation. |
| The "If-Range" header field allows a client to "short-circuit" the |  | The "If-Range" header field allows a client to "short-circuit" the |
| second request. Informally, its meaning is "if the representation is |  | second request. Informally, its meaning is: if the representation is |
| unchanged, send me the part(s) that I am missing; otherwise, send me |  | unchanged, send me the part(s) that I am requesting in Range; |
| the entire new representation". |  | otherwise, send me the entire representation. |
| If-Range = entity-tag / HTTP-date |  | If-Range = entity-tag / HTTP-date |
| Clients MUST NOT use an entity-tag marked as weak in an If-Range |  | Clients MUST NOT use an entity-tag marked as weak in an If-Range |
| field value and MUST NOT use a Last-Modified date in an If-Range |  | field value and MUST NOT use a Last-Modified date in an If-Range |
| field value unless it has no entity-tag for the representation and |  | field value unless it has no entity-tag for the representation and |
| the Last-Modified date it does have for the representation is strong |  | the Last-Modified date it does have for the representation is strong |
| in the sense defined by Section 2.2.2 of [Part4]. |  | in the sense defined by Section 2.2.2 of [Part4]. |
| A server that evaluates a conditional range request that is |  | A server that evaluates a conditional range request that is |
| applicable to one of its representations MUST evaluate the condition |  | applicable to one of its representations MUST evaluate the condition |
| as false if the entity-tag used as a validator is marked as weak or, |  | as false if the entity-tag used as a validator is marked as weak or, |
| when an HTTP-date is used as the validator, if the date value is not |  | when an HTTP-date is used as the validator, if the date value is not |
| strong in the sense defined by Section 2.2.2 of [Part4]. (A server |  | strong in the sense defined by Section 2.2.2 of [Part4]. (A server |
| can distinguish between a valid HTTP-date and any form of entity-tag |  | can distinguish between a valid HTTP-date and any form of entity-tag |
| by examining the first two characters.) |  | by examining the first two characters.) |
| The If-Range header field SHOULD only be sent by clients together |  | A client MUST NOT generate an If-Range header field in a request that |
| with a Range header field. The If-Range header field MUST be ignored |  | does not contain a Range header field. A server MUST ignore an If- |
| if it is received in a request that does not include a Range header |  | Range header field received in a request that does not contain a |
| field. The If-Range header field MUST be ignored by a server that |  | Range header field. An origin server MUST ignore an If-Range header |
| does not support the sub-range operation. |  | field received in a request for a target resource that does not |
|  |  | support Range requests. |
| If the validator given in the If-Range header field matches the |  | If the validator given in the If-Range header field matches the |
| current validator for the selected representation of the target |  | current validator for the selected representation of the target |
| resource, then the server SHOULD send the specified sub-range of the |  | resource, then the server SHOULD process the Range header field as |
| representation using a 206 (Partial Content) response. If the |  | requested. If the validator does not match, then the server MUST |
| validator does not match, then the server SHOULD send the entire |  | ignore the Range header field. |
| representation using a 200 (OK) response. |  |  |
| 5.4. Range |  | 4. Responses to a Range Request |
|  |  | 4.1. 206 Partial Content |
| 5.4.1. Byte Ranges |  | 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 requests's Range |
|  |  | header field (Section 3.1). |
| Since all HTTP representations are transferred as sequences of bytes, |  | If a single part is being transferred, the server generating the 206 |
| the concept of a byte range is meaningful for any HTTP |  | response MUST generate a Content-Range header field, describing what |
| representation. (However, not all clients and servers need to |  | range of the selected representation is enclosed, and a payload |
| support byte-range operations.) |  | consisting of the range. For example: |
| Byte range specifications in HTTP apply to the sequence of bytes in |  |  |
| the representation data (not necessarily the same as the message |  |  |
| body). |  |  |
| A byte range operation MAY specify a single range of bytes, or a set |  | HTTP/1.1 206 Partial Content |
| of ranges within a single representation. |  | 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 |
| byte-ranges-specifier = bytes-unit "=" byte-range-set |  | ... 26012 bytes of partial image data ... |
| 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 |  | If multiple parts are being transferred, the server generating the |
| of the first byte in a range. The last-byte-pos value gives the |  | 206 response MUST generate a "multipart/byteranges" payload, as |
| byte-offset of the last byte in the range; that is, the byte |  | defined in Appendix A, and a Content-Type header field containing the |
| positions specified are inclusive. Byte offsets start at zero. |  | 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 block of a |
|  |  | multiple part response (this field will be sent in each part |
|  |  | instead). |
| If the last-byte-pos value is present, it MUST be greater than or |  | Within the header area of each body part in the multipart payload, |
| equal to the first-byte-pos in that byte-range-spec, or the byte- |  | the server MUST generate a Content-Range header field corresponding |
| range-spec is syntactically invalid. The recipient of a byte-range- |  | to the range being enclosed in that body part. If the selected |
| set that includes one or more syntactically invalid byte-range-spec |  | representation would have had a Content-Type header field in a 200 |
| values MUST ignore the header field that includes that byte-range- |  | (OK) response, the server SHOULD generate that same Content-Type |
| set. |  | field in the header area of each body part. For example: |
| If the last-byte-pos value is absent, or if the value is greater than |  | HTTP/1.1 206 Partial Content |
| or equal to the current length of the representation data, last-byte- |  | Date: Wed, 15 Nov 1995 06:25:24 GMT |
| pos is taken to be equal to one less than the current length of the |  | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
| representation in bytes. |  | Content-Length: 1741 |
|  |  | Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
| By its choice of last-byte-pos, a client can limit the number of |  | --THIS_STRING_SEPARATES |
| bytes retrieved without knowing the size of the representation. |  | Content-Type: application/pdf |
|  |  | Content-Range: bytes 500-999/8000 |
| suffix-byte-range-spec = "-" suffix-length |  | ...the first range... |
| suffix-length = 1*DIGIT |  | --THIS_STRING_SEPARATES |
|  |  | Content-Type: application/pdf |
|  |  | Content-Range: bytes 7000-7999/8000 |
| A suffix-byte-range-spec is used to specify the suffix of the |  | ...the second range |
| representation data, of a length given by the suffix-length value. |  | --THIS_STRING_SEPARATES-- |
| (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- |  | When multiple ranges are requested, a server MAY coalesce any of the |
| range-spec whose first-byte-pos is less than the current length of |  | ranges that overlap or that are separated by a gap that is smaller |
| the representation, or at least one suffix-byte-range-spec with a |  | than the overhead of sending multiple parts, regardless of the order |
| non-zero suffix-length, then the byte-range-set is satisfiable. |  | in which the corresponding byte-range-spec appeared in the received |
| Otherwise, the byte-range-set is unsatisfiable. If the byte-range- |  | Range header field. Since the typical overhead between parts of a |
| set is unsatisfiable, the server SHOULD return a response with a 416 |  | multipart/byteranges payload is around 80 bytes, depending on the |
| (Requested Range Not Satisfiable) status code. Otherwise, the server |  | selected representation's media type and the chosen boundary |
| SHOULD return a response with a 206 (Partial Content) status code |  | parameter length, it can be less efficient to transfer many small |
| containing the satisfiable ranges of the representation. |  | disjoint parts than it is to transfer the entire selected |
|  |  | representation. |
| In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- |  | A server MUST NOT generate a multipart response to a request for a |
| length are expressed as decimal number of octets. Since there is no |  | single range, since a client that does not request multiple parts |
| predefined limit to the length of an HTTP payload, recipients SHOULD |  | might not support multipart responses. However, a server MAY |
| anticipate potentially large decimal numerals and prevent parsing |  | generate a multipart/byteranges payload with only a single body part |
| errors due to integer conversion overflows. |  | 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 ask for |
|  |  | multiple ranges in a single request. |
| Examples of byte-ranges-specifier values (assuming a representation |  | When a multipart response payload is generated, the server SHOULD |
| of length 10000): |  | send the parts in the same order that the corresponding byte-range- |
|  |  | spec appeared in the received Range header field, 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. |
| o The first 500 bytes (byte offsets 0-499, inclusive): |  | 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. |
| bytes=0-499 |  | 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. |
| o The second 500 bytes (byte offsets 500-999, inclusive): |  | A 206 response is cacheable unless otherwise indicated by explicit |
|  |  | cache controls (see Section 4.1.2 of [Part6]). |
| bytes=500-999 |  | 4.2. Content-Range |
| o The final 500 bytes (byte offsets 9500-9999, inclusive): |  | 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. |
| bytes=-500 |  | Content-Range = byte-content-range |
|  |  | / other-content-range |
| Or: |  | byte-content-range = bytes-unit SP |
|  |  | ( byte-range-resp / unsatisfied-range ) |
| bytes=9500- |  | byte-range-resp = byte-range "/" ( complete-length / "*" ) |
|  |  | byte-range = first-byte-pos "-" last-byte-pos |
|  |  | unsatisfied-range = "*/" complete-length |
| o The first and last bytes only (bytes 0 and 9999): |  | complete-length = 1*DIGIT |
| bytes=0-0,-1 |  | other-content-range = other-range-unit SP other-range-resp |
|  |  | other-range-resp = *CHAR |
| o Several legal but not canonical specifications of the second 500 |  | If a 206 (Partial Content) response contains a Content-Range header |
| bytes (byte offsets 500-999, inclusive): |  | 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. |
| bytes=500-600,601-999 |  | For byte ranges, a sender SHOULD indicate the complete length of the |
| bytes=500-700,601-999 |  | 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. |
| 5.4.2. Range Retrieval Requests |  | The following example illustrates when the complete length of the |
|  |  | selected representation is known by the sender to be 1234 bytes: |
| The "Range" header field defines the GET method (conditional or not) |  | Content-Range: bytes 42-1233/1234 |
| to request one or more sub-ranges of the response representation |  |  |
| data, instead of the entire representation data. |  |  |
| Range = byte-ranges-specifier / other-ranges-specifier |  | and this second example illustrates when the complete length is |
| other-ranges-specifier = other-range-unit "=" other-range-set |  | unknown: |
| other-range-set = 1*CHAR |  |  |
| A server MAY ignore the Range header field. However, origin servers |  | Content-Range: bytes 42-1233/* |
| 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 field and the specified range |  | A Content-Range field value is invalid if it contains a byte-range- |
| or ranges are appropriate for the representation: |  | 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. |
| o The presence of a Range header field in an unconditional GET |  | A server generating a 416 (Range Not Satisfiable) response to a byte |
| modifies what is returned if the GET is otherwise successful. In |  | range request SHOULD send a Content-Range header field with an |
| other words, the response carries a status code of 206 (Partial |  | unsatisfied-range value, as in the following example: |
| Content) instead of 200 (OK). |  |  |
| o The presence of a Range header field in a conditional GET (a |  | Content-Range: bytes */1234 |
| 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 |  | The complete-length in a 416 response indicates the current length of |
| header field (see Section 5.3) in addition to the Range header field. |  | the selected representation. |
| If a proxy that supports ranges receives a Range request, forwards |  | The "Content-Range" header field has no meaning for status codes that |
| the request to an inbound server, and receives an entire |  | do not explicitly describe its semantic. For this specification, |
| representation in reply, it MAY only return the requested range to |  | only the 206 (Partial Content) and 416 (Range Not Satisfiable) status |
| its client. |  | codes describe a meaning for Content-Range. |
| 6. IANA Considerations |  | The following are examples of Content-Range values in which the |
|  |  | selected representation contains a total of 1234 bytes: |
| 6.1. Status Code Registration |  | 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, where "strong validator" is defined to be |
|  |  | either an entity-tag that is not marked as weak (Section 2.3 of |
|  |  | [Part4]) or, if no entity-tag is provided, a Last-Modified value that |
|  |  | is strong in the sense defined by Section 2.2.2 of [Part4]. |
|  |  | 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. |
|  |  | 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 record 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 record 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: Mon, 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 200 (OK) if the requested |
|  |  | ranges are invalid or not satisfiable. 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. |
|  |  | 5. IANA Considerations |
|  |  | 5.1. Range Unit Registry |
|  |  | The HTTP Range Unit Registry defines the name space for the range |
|  |  | unit names and refers to their corresponding specifications. The |
|  |  | registry is maintained at |
|  |  | <http://www.iana.org/assignments/http-parameters>. |
|  |  | 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 name space require IETF Review (see |
|  |  | [RFC5226], Section 4.1). |
|  |  | 5.1.2. Registrations |
|  |  | The initial HTTP Range Unit Registry shall contain 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". |
|  |  | 5.2. Status Code Registration |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| <http://www.iana.org/assignments/http-status-codes> shall be updated |  | <http://www.iana.org/assignments/http-status-codes> shall be updated |
| with the registrations below: |  | with the registrations below: |
| +-------+---------------------------------+-------------+ |  | +-------+-----------------------+-------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+---------------------------------+-------------+ |  | +-------+-----------------------+-------------+ |
| | 206 | Partial Content | Section 3.1 | |  | | 206 | Partial Content | Section 4.1 | |
| | 416 | Requested Range Not Satisfiable | Section 3.2 | |  | | 416 | Range Not Satisfiable | Section 4.4 | |
| +-------+---------------------------------+-------------+ |  | +-------+-----------------------+-------------+ |
| 6.2. Header Field Registration |  | 5.3. Header Field Registration |
| The Message Header Field Registry located at <http://www.iana.org/ |  | The Message Header Field Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> shall be |  | assignments/message-headers/message-header-index.html> shall be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [BCP90]): |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Accept-Ranges | http | standard | Section 5.1 | |  | | Accept-Ranges | http | standard | Section 2.3 | |
| | Content-Range | http | standard | Section 5.2 | |  | | Content-Range | http | standard | Section 4.2 | |
| | If-Range | http | standard | Section 5.3 | |  | | If-Range | http | standard | Section 3.2 | |
| | Range | http | standard | Section 5.4 | |  | | Range | http | standard | Section 3.1 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 6.3. Range Specifier Registration |  | 6. Security Considerations |
| 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 | Description | Reference | |  |  |
| | Specifier | | | |  |  |
| | Name | | | |  |  |
| +---------------+-------------------------------------+-------------+ |  |  |
| | bytes | a range of octets | Section 2 | |  |  |
| | none | reserved as keyword, indicating no | Section 5.1 | |  |  |
| | | ranges are supported | | |  |  |
| +---------------+-------------------------------------+-------------+ |  |  |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  |  |
| Engineering Task Force". |  |  |
| 7. Security Considerations |  |  |
| This section is meant to inform application developers, information |  | This section is meant to inform developers, information providers, |
| providers, and users of the security limitations in HTTP/1.1 as |  | and users of known security concerns specific to the HTTP/1.1 range |
| described by this document. The discussion does not include |  | request mechanisms. More general security considerations are |
| definitive solutions to the problems revealed, though it does make |  | addressed in HTTP messaging [Part1] and semantics [Part2]. |
| some suggestions for reducing security risks. |  |  |
| 7.1. Overlapping Ranges |  | 6.1. Denial of Service Attacks using Range |
| Range requests containing overlapping ranges can lead to the |  | Unconstrained multiple range requests are susceptible to denial of |
| situation where a server is sending far more data than the size of |  | service attacks because the effort required to request many |
| the complete resource representation. |  | 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. |
| 8. Acknowledgments |  | 7. Acknowledgments |
| See Section 9 of [Part1]. |  | See Section 9 of [Part1]. |
| 9. References |  | 8. References |
| 9.1. Normative References |  | 8.1. Normative References |
| [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Message Syntax and Routing", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-21 (work in progress), |  | draft-ietf-httpbis-p1-messaging-22 (work in progress), |
| October 2012. |  | February 2013. |
| [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Semantics and Content", |  | Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-21 (work in progress), |  | draft-ietf-httpbis-p2-semantics-22 (work in progress), |
| October 2012. |  | February 2013. |
| [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Conditional Requests", |  | Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-21 (work in progress), |  | draft-ietf-httpbis-p4-conditional-22 (work in progress), |
| October 2012. |  | February 2013. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-21 (work in progress), |  | draft-ietf-httpbis-p6-cache-22 (work in progress), |
| October 2012. |  | February 2013. |
| [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| Extensions (MIME) Part Two: Media Types", RFC 2046, |  | Extensions (MIME) Part Two: Media Types", RFC 2046, |
| November 1996. |  | November 1996. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 9.2. Informative References |  | 8.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Specifications and Registration Procedures", BCP 13, |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | RFC 6838, January 2013. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | 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 |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
| May 2008. |  | May 2008. |
| Appendix A. Internet Media Type multipart/byteranges |  | Appendix A. Internet Media Type multipart/byteranges |
| When an HTTP 206 (Partial Content) response message includes the |  | When a 206 (Partial Content) response message includes the content of |
| content of multiple ranges (a response to a request for multiple non- |  | multiple ranges, they are transmitted as body parts in a multipart |
| overlapping ranges), these are transmitted as a multipart message |  | message body ([RFC2046], Section 5.1) with the media type of |
| body ([RFC2046], Section 5.1). The media type for this purpose is |  | "multipart/byteranges". The following definition is to be registered |
| called "multipart/byteranges". The following is to be registered |  | with IANA [BCP13]. |
| with IANA [RFC4288]. |  |  |
| The multipart/byteranges media type includes one or more parts, each |  | The multipart/byteranges media type includes one or more body parts, |
| with its own Content-Type and Content-Range fields. The required |  | each with its own Content-Type and Content-Range fields. The |
| boundary parameter specifies the boundary string used to separate |  | required boundary parameter specifies the boundary string used to |
| each body-part. |  | separate each body part. |
| Type name: multipart |  | Type name: multipart |
| Subtype name: byteranges |  | Subtype name: byteranges |
| Required parameters: boundary |  | Required parameters: boundary |
| Optional parameters: none |  | Optional parameters: none |
| Encoding considerations: only "7bit", "8bit", or "binary" are |  | Encoding considerations: only "7bit", "8bit", or "binary" are |
| skipping to change at page 18, line 22 |  | skipping to change at page 19, line 47 |
| Person and email address to contact for further information: See |  | Person and email address to contact for further information: See |
| Authors Section. |  | Authors Section. |
| Intended usage: COMMON |  | Intended usage: COMMON |
| Restrictions on usage: none |  | Restrictions on usage: none |
| Author/Change controller: IESG |  | Author/Change controller: IESG |
| Note: Despite the name "multipart/byteranges" is not limited to |  | Implementation Notes: |
| the byte ranges only. |  |  |
| 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 |  | 1. Additional CRLFs might precede the first boundary string in the |
| Content-type: application/pdf |  | body. |
| Content-range: bytes 500-999/8000 |  |  |
| ...the first range... |  | 2. Although [RFC2046] permits the boundary string to be quoted, some |
| --THIS_STRING_SEPARATES |  | existing implementations handle a quoted boundary string |
| Content-type: application/pdf |  | incorrectly. |
| Content-range: bytes 7000-7999/8000 |  |  |
| ...the second range |  | 3. A number of clients and servers were coded to an early draft of |
| --THIS_STRING_SEPARATES-- |  | the byteranges specification that used a media type of multipart/ |
|  |  | x-byteranges, which is almost (but not quite) compatible with |
|  |  | this type. |
| Another example, using the "exampleunit" range unit: |  | 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 |  | HTTP/1.1 206 Partial Content |
| Date: Tue, 14 Nov 1995 06:25:24 GMT |  | Date: Tue, 14 Nov 1995 06:25:24 GMT |
| Last-Modified: Tue, 14 July 04:58:08 GMT |  | Last-Modified: Tue, 14 July 04:58:08 GMT |
| Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |  | Content-Length: 2331785 |
|  |  | Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
| --THIS_STRING_SEPARATES |  | --THIS_STRING_SEPARATES |
| Content-type: video/example |  | Content-Type: video/example |
| Content-range: exampleunit 1.2-4.3/25 |  | Content-Range: exampleunit 1.2-4.3/25 |
| ...the first range... |  | ...the first range... |
| --THIS_STRING_SEPARATES |  | --THIS_STRING_SEPARATES |
| Content-type: video/example |  | Content-Type: video/example |
| Content-range: exampleunit 11.2-14.3/25 |  | Content-Range: exampleunit 11.2-14.3/25 |
| ...the second range |  | ...the second range |
| --THIS_STRING_SEPARATES-- |  | --THIS_STRING_SEPARATES-- |
| Notes: |  | Appendix B. Changes from RFC 2616 |
| 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. |  |  |
| 3. A number of clients and servers were coded to an early draft of |  | A weak validator cannot be used in a 206 response. (Section 4.1) |
| 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. Changes from RFC 2616 |  | The Content-Range header field only has meaning when the status code |
|  |  | explicitly defines its use. (Section 4.2) |
| Introduce Range Specifier Registry. (Section 2.1) |  | Servers are given more leeway in how they respond to a range request, |
|  |  | in order to mitigate abuse by malicious (or just greedy) clients. |
| Clarify that it is not ok to use a weak validator in a 206 response. |  | multipart/byteranges can consist of a single part. (Appendix A) |
| (Section 3.1) |  |  |
| Clarify that multipart/byteranges can consist of a single part. |  | This specification introduces a Range Unit Registry. (Section 5.1) |
| (Appendix A) |  |  |
| Appendix C. Imported ABNF |  | Appendix C. Imported ABNF |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
| CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |  | 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 |  | 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 |  | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| character). |  | character). |
| Note that all rules derived from token are to be compared case- |  | Note that all rules derived from token are to be compared case- |
| insensitively, like range-unit and acceptable-ranges. |  | insensitively, like range-unit and acceptable-ranges. |
| The rules below are defined in [Part1]: |  | The rules below are defined in [Part1]: |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.6> |
| The rules below are defined in other parts: |  | The rules below are defined in other parts: |
| HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1> |
| entity-tag = <entity-tag, defined in [Part4], Section 2.3> |  | entity-tag = <entity-tag, defined in [Part4], Section 2.3> |
| Appendix D. Collected ABNF |  | Appendix D. Collected ABNF |
| Accept-Ranges = acceptable-ranges |  | Accept-Ranges = acceptable-ranges |
| Content-Range = byte-content-range-spec / other-content-range-spec |  | Content-Range = byte-content-range / other-content-range |
| HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1> |
| If-Range = entity-tag / HTTP-date |  | If-Range = entity-tag / HTTP-date |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| Range = byte-ranges-specifier / other-ranges-specifier |  | Range = byte-ranges-specifier / other-ranges-specifier |
| acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS |  | acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS |
| range-unit ] ) ) / "none" |  | range-unit ] ) ) / "none" |
| byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( |  | byte-content-range = bytes-unit SP ( byte-range-resp / |
| instance-length / "*" ) |  | unsatisfied-range ) |
| byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" |  | byte-range = first-byte-pos "-" last-byte-pos |
|  |  | byte-range-resp = byte-range "/" ( complete-length / "*" ) |
| byte-range-set = *( "," OWS ) ( byte-range-spec / |  | byte-range-set = *( "," OWS ) ( byte-range-spec / |
| suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / |  | suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / |
| suffix-byte-range-spec ) ] ) |  | suffix-byte-range-spec ) ] ) |
| byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |  | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |
| byte-ranges-specifier = bytes-unit "=" byte-range-set |  | byte-ranges-specifier = bytes-unit "=" byte-range-set |
| bytes-unit = "bytes" |  | bytes-unit = "bytes" |
|  |  | complete-length = 1*DIGIT |
| entity-tag = <entity-tag, defined in [Part4], Section 2.3> |  | entity-tag = <entity-tag, defined in [Part4], Section 2.3> |
| first-byte-pos = 1*DIGIT |  | first-byte-pos = 1*DIGIT |
| instance-length = 1*DIGIT |  |  |
| last-byte-pos = 1*DIGIT |  | last-byte-pos = 1*DIGIT |
| other-content-range-spec = other-range-unit SP other-range-resp-spec |  | other-content-range = other-range-unit SP other-range-resp |
| other-range-resp-spec = *CHAR |  | other-range-resp = *CHAR |
| other-range-set = 1*CHAR |  | other-range-set = 1*CHAR |
| other-range-unit = token |  | other-range-unit = token |
| other-ranges-specifier = other-range-unit "=" other-range-set |  | other-ranges-specifier = other-range-unit "=" other-range-set |
| range-unit = bytes-unit / other-range-unit |  | range-unit = bytes-unit / other-range-unit |
| suffix-byte-range-spec = "-" suffix-length |  | suffix-byte-range-spec = "-" suffix-length |
| suffix-length = 1*DIGIT |  | suffix-length = 1*DIGIT |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.6> |
|  |  | unsatisfied-range = "*/" complete-length |
| Appendix E. Change Log (to be removed by RFC Editor before publication) |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
| Changes up to the first Working Group Last Call draft are summarized |  | Changes up to the first Working Group Last Call draft are summarized |
| in <http://tools.ietf.org/html/ |  | in <http://tools.ietf.org/html/ |
| draft-ietf-httpbis-p5-range-19#appendix-D>. |  | draft-ietf-httpbis-p5-range-19#appendix-D>. |
| E.1. Since draft-ietf-httpbis-p5-range-19 |  | E.1. Since draft-ietf-httpbis-p5-range-19 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 22, line 35 |  | skipping to change at page 23, line 35 |
| introduction of new IANA registries as normative changes" |  | introduction of new IANA registries as normative changes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units |
| vs leading zeroes vs size" |  | vs leading zeroes vs size" |
| E.2. Since draft-ietf-httpbis-p5-range-20 |  | E.2. Since draft-ietf-httpbis-p5-range-20 |
| o Conformance criteria and considerations regarding error handling |  | o Conformance criteria and considerations regarding error handling |
| are now defined in Part 1. |  | are now defined in Part 1. |
|  |  | E.3. Since draft-ietf-httpbis-p5-range-21 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security |
|  |  | consideration: range flooding" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing |
|  |  | heuristic caching for new status codes" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add |
|  |  | limitations to Range to reduce its use as a denial-of-service |
|  |  | tool" |
| Index |  | Index |
| 2 |  | 2 |
| 206 Partial Content (status code) 5 |  | 206 Partial Content (status code) 10 |
| 4 |  | 4 |
| 416 Requested Range Not Satisfiable (status code) 6 |  | 416 Range Not Satisfiable (status code) 15 |
| A |  | A |
| Accept-Ranges header field 8 |  | Accept-Ranges header field 7 |
| C |  | C |
| Content-Range header field 9 |  | Content-Range header field 12 |
| G |  | G |
| Grammar |  | Grammar |
| Accept-Ranges 8 |  | Accept-Ranges 7 |
| acceptable-ranges 8 |  | acceptable-ranges 7 |
| byte-content-range-spec 9 |  | byte-content-range 12 |
| byte-range-resp-spec 9 |  | byte-range 12 |
| byte-range-set 12 |  | byte-range-resp 12 |
| byte-range-spec 12 |  | byte-range-set 5 |
| byte-ranges-specifier 12 |  | byte-range-spec 5 |
|  |  | byte-ranges-specifier 5 |
| bytes-unit 5 |  | bytes-unit 5 |
| Content-Range 9 |  | complete-length 12 |
| first-byte-pos 12 |  | Content-Range 12 |
| If-Range 11 |  | first-byte-pos 5 |
| instance-length 9 |  | If-Range 9 |
| last-byte-pos 12 |  | last-byte-pos 5 |
| other-range-unit 5 |  | other-content-range 12 |
| Range 13 |  | other-range-resp 12 |
|  |  | other-range-unit 5, 7 |
|  |  | Range 7 |
| range-unit 5 |  | range-unit 5 |
| ranges-specifier 12 |  | ranges-specifier 5 |
| suffix-byte-range-spec 12 |  | suffix-byte-range-spec 6 |
| suffix-length 12 |  | suffix-length 6 |
|  |  | unsatisfied-range 12 |
| I |  | I |
| If-Range header field 10 |  | If-Range header field 9 |
| M |  | M |
| Media Type |  | Media Type |
| multipart/byteranges 17 |  | multipart/byteranges 18 |
| multipart/x-byteranges 19 |  | multipart/x-byteranges 20 |
| multipart/byteranges Media Type 17 |  | multipart/byteranges Media Type 18 |
| multipart/x-byteranges Media Type 19 |  | multipart/x-byteranges Media Type 20 |
| R |  | R |
| Range header field 11 |  | Range header field 7 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 156 change blocks.
| 549 lines changed or deleted |  | 610 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/