| draft-ietf-httpbis-p5-range-23.txt |  | draft-ietf-httpbis-p5-range-24.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: January 16, 2014 J. Reschke, Ed. |  | Expires: March 29, 2014 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 15, 2013 |  | September 25, 2013 |
| Hypertext Transfer Protocol (HTTP/1.1): Range Requests |  | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| draft-ietf-httpbis-p5-range-23 |  | draft-ietf-httpbis-p5-range-24 |
| 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.4. |  | The changes in this draft are summarized in Appendix E.5. |
| 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 January 16, 2014. |  | This Internet-Draft will expire on March 29, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 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 |
| skipping to change at page 3, line 17 |  | skipping to change at page 3, line 17 |
| 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. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 |
| 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10 |  | 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9 |
| 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 |  | 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 |
| 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 |  | 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 |
| 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 |  | 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 |
| 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 |  | 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |
| 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 |  | 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 |
| 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 |  | 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 |
| 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 |  | 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 |
| 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 |  | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 |
| 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 |  | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 |
| skipping to change at page 3, line 44 |  | skipping to change at page 3, line 44 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 |  | Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 |
| 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) . . . . . . . . . . . . . . . . . . . . 23 |  | publication) . . . . . . . . . . . . . . . . . . . . 23 |
| E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 |  | E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 |
| E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 |  | E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 |
| E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 |  | E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 |
| E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24 |  | E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24 |
|  |  | E.5. Since draft-ietf-httpbis-p5-range-23 . . . . . . . . . . . 24 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 1. Introduction |  | 1. Introduction |
| Hypertext Transfer Protocol (HTTP) clients often encounter |  | Hypertext Transfer Protocol (HTTP) clients often encounter |
| interrupted data transfers as a result of canceled requests or |  | interrupted data transfers as a result of canceled requests or |
| dropped connections. When a client has stored a partial |  | dropped connections. When a client has stored a partial |
| representation, it is desirable to request the remainder of that |  | representation, it is desirable to request the remainder of that |
| representation in a subsequent request rather than transfer the |  | representation in a subsequent request rather than transfer the |
| entire representation. Likewise, devices with limited local storage |  | entire representation. Likewise, devices with limited local storage |
| skipping to change at page 4, line 43 |  | skipping to change at page 4, line 43 |
| "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 |
| defined in Section 2.5 of [Part1]. |  | defined in Section 2.5 of [Part1]. |
| 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 |  | 7 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 |
| A representation can be partitioned into subranges according to |  | A representation can be partitioned into subranges according to |
| various structural units, depending on the structure inherent in the |  | various structural units, depending on the structure inherent in the |
| representation's media type. This "range unit" is used in the |  | representation's media type. This "range unit" is used in the |
| Accept-Ranges (Section 2.3) response header field to advertise |  | Accept-Ranges (Section 2.3) response header field to advertise |
| support for range requests, the Range (Section 3.1) request header |  | support for range requests, the Range (Section 3.1) request header |
| skipping to change at page 7, line 20 |  | skipping to change at page 7, line 20 |
| other-range-unit = token |  | other-range-unit = token |
| 2.3. Accept-Ranges |  | 2.3. Accept-Ranges |
| The "Accept-Ranges" header field allows a server to indicate that it |  | The "Accept-Ranges" header field allows a server to indicate that it |
| supports range requests for the target resource. |  | 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 support byte-range requests MAY send |  | An origin server that supports byte-range requests for a given target |
|  |  | resource MAY send |
| Accept-Ranges: bytes |  | Accept-Ranges: bytes |
| but are not required to do so. Clients MAY generate range requests |  | to indicate what range units are supported. A client MAY generate |
| without having received this header field for the resource involved. |  | range requests without having received this header field for the |
| Range units are defined in Section 2. |  | resource involved. Range units are defined in Section 2. |
| Servers that do not support any kind of range request for the target |  | A server that does not support any kind of range request for the |
| resource resource MAY send |  | target 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. |
| 3. Range Requests |  | 3. Range Requests |
| 3.1. Range |  | 3.1. Range |
| The "Range" header field on a GET request modifies the method |  | The "Range" header field on a GET request modifies the method |
| skipping to change at page 8, line 7 |  | skipping to change at page 8, line 8 |
| other-range-set = 1*CHAR |  | other-range-set = 1*CHAR |
| A server MAY ignore the Range header field. However, origin servers |  | A server MAY ignore the Range header field. However, origin servers |
| and intermediate caches ought to support byte ranges when possible, |  | and intermediate caches ought to support byte ranges when possible, |
| since Range supports efficient recovery from partially failed |  | since Range supports efficient recovery from partially failed |
| transfers and partial retrieval of large representations. A server |  | transfers and partial retrieval of large representations. A server |
| MUST ignore a Range header field received with a request method other |  | MUST ignore a Range header field received with a request method other |
| than GET. |  | than GET. |
| An origin server MUST ignore a Range header field that contains a |  | 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 unit it does not understand. A proxy MAY discard a Range |
| Range header field that contains a range unit it does not understand |  | header field that contains a range unit it does not understand. |
| or pass it to the next inbound server when forwarding the request. |  |  |
| A server that supports range requests ought to ignore or reject a |  | A server that supports range requests MAY ignore or reject a Range |
| Range header field that consists of more than two overlapping ranges, |  | header field that consists of more than two overlapping ranges, or a |
| or a set of many small ranges that are not listed in ascending order, |  | set of many small ranges that are not listed in ascending order, |
| since both are indications of either a broken client or a deliberate |  | since both are indications of either a broken client or a deliberate |
| denial of service attack (Section 6.1). A client SHOULD NOT request |  | denial of service attack (Section 6.1). A client SHOULD NOT request |
| multiple ranges that are inherently less efficient to process and |  | multiple ranges that are inherently less efficient to process and |
| transfer than a single range that encompasses the same data. |  | transfer than a single range that encompasses the same data. |
| A client that is requesting multiple ranges SHOULD list those ranges |  | A client that is requesting multiple ranges SHOULD list those ranges |
| in ascending order (the order in which they would typically be |  | in ascending order (the order in which they would typically be |
| received in a complete representation) unless there is a specific |  | received in a complete representation) unless there is a specific |
| need to request a later part earlier. For example, a user agent |  | need to request a later part earlier. For example, a user agent |
| processing a large representation with an internal catalog of parts |  | processing a large representation with an internal catalog of parts |
| skipping to change at page 9, line 10 |  | skipping to change at page 9, line 10 |
| If all of the preconditions are true, the server supports the Range |  | If all of the preconditions are true, the server supports the Range |
| header field for the target resource, and the specified range(s) are |  | header field for the target resource, and the specified range(s) are |
| invalid or unsatisfiable, the server SHOULD send a 416 (Range Not |  | invalid or unsatisfiable, the server SHOULD send a 416 (Range Not |
| Satisfiable) response. |  | Satisfiable) response. |
| 3.2. 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 precondition |
| because the representation has been modified, the client would then |  | fails because the representation has been modified, the client would |
| have to make a second request to obtain the entire current |  | then 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 requesting in Range; |  | unchanged, send me the part(s) that I am requesting in Range; |
| otherwise, send me the entire representation. |  | otherwise, send me the entire representation. |
| If-Range = entity-tag / HTTP-date |  | If-Range = entity-tag / HTTP-date |
| A client MUST NOT generate an If-Range header field containing an |  |  |
| entity-tag that is marked as weak. A client MUST NOT generate an If- |  |  |
| Range header field containing a Last-Modified date unless the client |  |  |
| has no entity-tag for the corresponding representation and the Last- |  |  |
| Modified date is strong in the sense defined by Section 2.2.2 of |  |  |
| [Part4]. |  |  |
| A server that evaluates a conditional range request that is |  |  |
| 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, |  |  |
| 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 |  |  |
| can distinguish between a valid HTTP-date and any form of entity-tag |  |  |
| by examining the first two characters.) |  |  |
| A client MUST NOT generate an If-Range header field in a request that |  | A client MUST NOT generate an If-Range header field in a request that |
| does not contain a Range header field. A server MUST ignore an If- |  | does not contain a Range header field. A server MUST ignore an If- |
| Range header field received in a request that does not contain a |  | Range header field received in a request that does not contain a |
| Range header field. An origin server MUST ignore an If-Range header |  | Range header field. An origin server MUST ignore an If-Range header |
| field received in a request for a target resource that does not |  | field received in a request for a target resource that does not |
| support Range requests. |  | support Range requests. |
|  |  | A client MUST NOT generate an If-Range header field containing an |
|  |  | entity-tag that is marked as weak. A client MUST NOT generate an If- |
|  |  | Range header field containing an HTTP-date unless the client has no |
|  |  | entity-tag for the corresponding representation and the date is a |
|  |  | strong validator in the sense defined by Section 2.2.2 of [Part4]. |
|  |  | A server that evaluates an If-Range precondition MUST use the strong |
|  |  | comparison function when comparing entity-tags (Section 2.3.2 of |
|  |  | [Part4]) and MUST evaluate the condition as false if an HTTP-date |
|  |  | validator is provided that is not a strong validator 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 by examining the |
|  |  | first two characters.) |
| 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 process the Range header field as |  | resource, then the server SHOULD process the Range header field as |
| requested. If the validator does not match, then the server MUST |  | requested. If the validator does not match, the server MUST ignore |
| ignore the Range header field. |  | the Range header field. |
| 4. Responses to a Range Request |  | 4. Responses to a Range Request |
| 4.1. 206 Partial Content |  | 4.1. 206 Partial Content |
| The 206 (Partial Content) status code indicates that the server is |  | The 206 (Partial Content) status code indicates that the server is |
| successfully fulfilling a range request for the target resource by |  | successfully fulfilling a range request for the target resource by |
| transferring one or more parts of the selected representation that |  | transferring one or more parts of the selected representation that |
| correspond to the satisfiable ranges found in the request's Range |  | correspond to the satisfiable ranges found in the request's Range |
| header field (Section 3.1). |  | header field (Section 3.1). |
| If a single part is being transferred, the server generating the 206 |  | If a single part is being transferred, the server generating the 206 |
| response MUST generate a Content-Range header field, describing what |  | response MUST generate a Content-Range header field, describing what |
| skipping to change at page 10, line 34 |  | skipping to change at page 10, line 31 |
| Content-Length: 26012 |  | Content-Length: 26012 |
| Content-Type: image/gif |  | Content-Type: image/gif |
| ... 26012 bytes of partial image data ... |  | ... 26012 bytes of partial image data ... |
| If multiple parts are being transferred, the server generating the |  | If multiple parts are being transferred, the server generating the |
| 206 response MUST generate a "multipart/byteranges" payload, as |  | 206 response MUST generate a "multipart/byteranges" payload, as |
| defined in Appendix A, and a Content-Type header field containing the |  | defined in Appendix A, and a Content-Type header field containing the |
| multipart/byteranges media type and its required boundary parameter. |  | multipart/byteranges media type and its required boundary parameter. |
| To avoid confusion with single part responses, a server MUST NOT |  | To avoid confusion with single part responses, a server MUST NOT |
| generate a Content-Range header field in the HTTP header block of a |  | generate a Content-Range header field in the HTTP header section of a |
| multiple part response (this field will be sent in each part |  | multiple part response (this field will be sent in each part |
| instead). |  | instead). |
| Within the header area of each body part in the multipart payload, |  | Within the header area of each body part in the multipart payload, |
| the server MUST generate a Content-Range header field corresponding |  | the server MUST generate a Content-Range header field corresponding |
| to the range being enclosed in that body part. If the selected |  | to the range being enclosed in that body part. If the selected |
| representation would have had a Content-Type header field in a 200 |  | representation would have had a Content-Type header field in a 200 |
| (OK) response, the server SHOULD generate that same Content-Type |  | (OK) response, the server SHOULD generate that same Content-Type |
| field in the header area of each body part. For example: |  | field in the header area of each body part. For example: |
| skipping to change at page 12, line 20 |  | skipping to change at page 12, line 20 |
| If a 206 is generated in response to a request with an If-Range |  | If a 206 is generated in response to a request with an If-Range |
| header field, the sender SHOULD NOT generate other representation |  | header field, the sender SHOULD NOT generate other representation |
| header fields beyond those required above, because the client is |  | header fields beyond those required above, because the client is |
| understood to already have a prior response containing those header |  | understood to already have a prior response containing those header |
| fields. Otherwise, the sender MUST generate all of the |  | fields. Otherwise, the sender MUST generate all of the |
| representation header fields that would have been sent in a 200 (OK) |  | representation header fields that would have been sent in a 200 (OK) |
| response to the same request. |  | response to the same request. |
| A 206 response is cacheable unless otherwise indicated by explicit |  | A 206 response is cacheable unless otherwise indicated by explicit |
| cache controls (see Section 4.1.2 of [Part6]). |  | cache controls (see Section 4.2.2 of [Part6]). |
| 4.2. Content-Range |  | 4.2. Content-Range |
| The "Content-Range" header field is sent in a single part 206 |  | The "Content-Range" header field is sent in a single part 206 |
| (Partial Content) response to indicate the partial range of the |  | (Partial Content) response to indicate the partial range of the |
| selected representation enclosed as the message payload, sent in each |  | selected representation enclosed as the message payload, sent in each |
| part of a multipart 206 response to indicate the range enclosed |  | part of a multipart 206 response to indicate the range enclosed |
| within each body part, and sent in 416 (Range Not Satisfiable) |  | within each body part, and sent in 416 (Range Not Satisfiable) |
| responses to provide information about the selected representation. |  | responses to provide information about the selected representation. |
| skipping to change at page 14, line 20 |  | skipping to change at page 14, line 20 |
| Content-Range: bytes 734-1233/1234 |  | Content-Range: bytes 734-1233/1234 |
| 4.3. Combining Ranges |  | 4.3. Combining Ranges |
| A response might transfer only a subrange of a representation if the |  | A response might transfer only a subrange of a representation if the |
| connection closed prematurely or if the request used one or more |  | connection closed prematurely or if the request used one or more |
| Range specifications. After several such transfers, a client might |  | Range specifications. After several such transfers, a client might |
| have received several ranges of the same representation. These |  | have received several ranges of the same representation. These |
| ranges can only be safely combined if they all have in common the |  | ranges can only be safely combined if they all have in common the |
| same strong validator, where "strong validator" is defined to be |  | same strong validator (Section 2.1 of [Part4]). |
| 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 |  | A client that has received multiple partial responses to GET requests |
| on a target resource MAY combine those responses into a larger |  | on a target resource MAY combine those responses into a larger |
| continuous range if they share the same strong validator. |  | continuous range if they share the same strong validator. |
| If the most recent response is an incomplete 200 (OK) response, then |  | If the most recent response is an incomplete 200 (OK) response, then |
| the header fields of that response are used for any combined response |  | the header fields of that response are used for any combined response |
| and replace those of the matching stored responses. |  | and replace those of the matching stored responses. |
| If the most recent response is a 206 (Partial Content) response and |  | If the most recent response is a 206 (Partial Content) response and |
| skipping to change at page 17, line 39 |  | skipping to change at page 17, line 39 |
| memory, and bandwidth consumed by attempting to serve the requested |  | memory, and bandwidth consumed by attempting to serve the requested |
| data in many parts. Servers ought to ignore, coalesce, or reject |  | data in many parts. Servers ought to ignore, coalesce, or reject |
| egregious range requests, such as requests for more than two |  | egregious range requests, such as requests for more than two |
| overlapping ranges or for many small ranges in a single set, |  | overlapping ranges or for many small ranges in a single set, |
| particularly when the ranges are requested out of order for no |  | particularly when the ranges are requested out of order for no |
| apparent reason. Multipart range requests are not designed to |  | apparent reason. Multipart range requests are not designed to |
| support random access. |  | support random access. |
| 7. Acknowledgments |  | 7. Acknowledgments |
| See Section 9 of [Part1]. |  | See Section 10 of [Part1]. |
| 8. References |  | 8. References |
| 8.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-23 (work in progress), |  | draft-ietf-httpbis-p1-messaging-24 (work in progress), |
| July 2013. |  | September 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-23 (work in progress), |  | draft-ietf-httpbis-p2-semantics-24 (work in progress), |
| July 2013. |  | September 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-23 (work in progress), |  | draft-ietf-httpbis-p4-conditional-24 (work in progress), |
| July 2013. |  | September 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-23 (work in progress), |  | draft-ietf-httpbis-p6-cache-24 (work in progress), |
| July 2013. |  | September 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. |
| skipping to change at page 20, line 38 |  | skipping to change at page 20, line 38 |
| ...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-- |
| Appendix B. Changes from RFC 2616 |  | Appendix B. Changes from RFC 2616 |
|  |  | Servers are given more leeway in how they respond to a range request, |
|  |  | in order to mitigate abuse by malicious (or just greedy) clients. |
|  |  | (Section 3.1) |
| A weak validator cannot be used in a 206 response. (Section 4.1) |  | A weak validator cannot be used in a 206 response. (Section 4.1) |
| The Content-Range header field only has meaning when the status code |  | The Content-Range header field only has meaning when the status code |
| explicitly defines its use. (Section 4.2) |  | explicitly defines its use. (Section 4.2) |
| Servers are given more leeway in how they respond to a range request, |  | This specification introduces a Range Unit Registry. (Section 5.1) |
| in order to mitigate abuse by malicious (or just greedy) clients. |  |  |
| multipart/byteranges can consist of a single part. (Appendix A) |  | multipart/byteranges can consist of a single part. (Appendix A) |
| This specification introduces a Range Unit Registry. (Section 5.1) |  |  |
| 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- |
| skipping to change at page 24, line 24 |  | skipping to change at page 24, line 24 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type |
| registration template issues" |  | registration template issues" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/462>: "Editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/462>: "Editorial |
| suggestions" |  | suggestions" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/485>: "MUSTs and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/485>: "MUSTs and |
| other feedback" |  | other feedback" |
|  |  | E.5. Since draft-ietf-httpbis-p5-range-23 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/489>: "is P5's |
|  |  | definition of strong validator consistent with P4?" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/490>: "p5 editorial |
|  |  | comments" |
| Index |  | Index |
| 2 |  | 2 |
| 206 Partial Content (status code) 10 |  | 206 Partial Content (status code) 10 |
| 4 |  | 4 |
| 416 Range Not Satisfiable (status code) 15 |  | 416 Range Not Satisfiable (status code) 15 |
| A |  | A |
| Accept-Ranges header field 7 |  | Accept-Ranges header field 7 |
End of changes. 30 change blocks.
| 59 lines changed or deleted |  | 66 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/