| draft-ietf-httpbis-p5-range-22.txt |  | draft-ietf-httpbis-p5-range-23.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: August 27, 2013 J. Reschke, Ed. |  | Expires: January 16, 2014 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| February 23, 2013 |  | July 15, 2013 |
| Hypertext Transfer Protocol (HTTP/1.1): Range Requests |  | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| draft-ietf-httpbis-p5-range-22 |  | draft-ietf-httpbis-p5-range-23 |
| 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.3. |  | The changes in this draft are summarized in Appendix E.4. |
| 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 August 27, 2013. |  | This Internet-Draft will expire on January 16, 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 . . . . . . . . . . . . . . . . . 9 |  | 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10 |
| 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 43 |  | skipping to change at page 3, line 43 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 |
| 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 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 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 |
| might benefit from being able to request only a subset of a larger |  | might benefit from being able to request only a subset of a larger |
| representation, such as a single page of a very large document, or |  | representation, such as a single page of a very large document, or |
| the dimensions of an embedded image. |  | 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, obsoleting those parts |  | the multipart/byteranges media type. Range requests are an OPTIONAL |
| previously defined in [RFC2616]. Range requests are an OPTIONAL |  |  |
| feature of HTTP, designed so that recipients not implementing this |  | feature of HTTP, designed so that recipients not implementing this |
| feature (or not supporting it for the target resource) can respond as |  | feature (or not supporting it for the target resource) can respond as |
| if it is a normal GET request without impacting interoperability. |  | if it is a normal GET request without impacting interoperability. |
| Partial responses are indicated by a distinct status code to not be |  | Partial responses are indicated by a distinct status code to not be |
| mistaken for full responses by caches that might not implement the |  | mistaken for full responses by caches that might not implement the |
| feature. |  | feature. |
| Although the 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. |
| skipping to change at page 5, line 22 |  | skipping to change at page 5, line 21 |
| 2.1. Byte Ranges |  | 2.1. Byte Ranges |
| Since representation data is transferred in payloads as a sequence of |  | Since representation data is transferred in payloads as a sequence of |
| octets, a byte range is a meaningful substructure for any |  | octets, a byte range is a meaningful substructure for any |
| representation transferable over HTTP (Section 3 of [Part2]). We |  | representation transferable over HTTP (Section 3 of [Part2]). We |
| define the "bytes" range unit for expressing subranges of the data's |  | define the "bytes" range unit for expressing subranges of the data's |
| octet sequence. |  | octet sequence. |
| bytes-unit = "bytes" |  | bytes-unit = "bytes" |
| A byte range operation MAY specify a single range of bytes, or a set |  | A byte range request can specify a single range of bytes, or a set of |
| of ranges within a single representation. |  | ranges within a single representation. |
| byte-ranges-specifier = bytes-unit "=" byte-range-set |  | byte-ranges-specifier = bytes-unit "=" byte-range-set |
| byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) |  | byte-range-set = 1#( 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 ] |
| first-byte-pos = 1*DIGIT |  | first-byte-pos = 1*DIGIT |
| last-byte-pos = 1*DIGIT |  | last-byte-pos = 1*DIGIT |
| The first-byte-pos value in a byte-range-spec gives the byte-offset |  | The first-byte-pos value in a byte-range-spec gives the byte-offset |
| of the first byte in a range. The last-byte-pos value gives the |  | of the first byte in a range. The last-byte-pos value gives the |
| byte-offset of the last byte in the range; that is, the byte |  | byte-offset of the last byte in the range; that is, the byte |
| skipping to change at page 6, line 16 |  | skipping to change at page 6, line 15 |
| value of last-byte-pos with a value that is one less than the current |  | value of last-byte-pos with a value that is one less than the current |
| length of the selected representation). |  | length of the selected representation). |
| A client can request the last N bytes of the selected representation |  | A client can request the last N bytes of the selected representation |
| using a suffix-byte-range-spec. |  | using a suffix-byte-range-spec. |
| suffix-byte-range-spec = "-" suffix-length |  | suffix-byte-range-spec = "-" suffix-length |
| suffix-length = 1*DIGIT |  | suffix-length = 1*DIGIT |
| If the selected representation is shorter than the specified suffix- |  | If the selected representation is shorter than the specified suffix- |
| length, the entire representation is used. For example (assuming a |  | length, the entire representation is used. |
| representation of length 10000): |  |  |
|  |  | Additional examples, assuming a representation of length 10000: |
| o The final 500 bytes (byte offsets 9500-9999, inclusive): |  | o The final 500 bytes (byte offsets 9500-9999, inclusive): |
| bytes=-500 |  | bytes=-500 |
| Or: |  | Or: |
| bytes=9500- |  | bytes=9500- |
| o The first and last bytes only (bytes 0 and 9999): |  | o The first and last bytes only (bytes 0 and 9999): |
| skipping to change at page 8, line 28 |  | skipping to change at page 8, line 28 |
| 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 |
| might need to request later parts first, particularly if the |  | might need to request later parts first, particularly if the |
| representation consists of pages stored in reverse order and the user |  | representation consists of pages stored in reverse order and the user |
| agent wishes to transfer one page at a time. |  | agent wishes to transfer one page at a time. |
| The Range header field is evaluated after evaluating the |  | The Range header field is evaluated after evaluating the precondition |
| preconditions of [Part4] and only if the result of their evaluation |  | header fields defined in [Part4], and only if the result in absence |
| is leading toward a 200 (OK) response. In other words, Range is |  | of the Range header field would be a 200 (OK) response. In other |
| ignored when a conditional GET would result in a 304 (Not Modified) |  | words, Range is ignored when a conditional GET would result in a 304 |
| response. |  | (Not Modified) response. |
| The If-Range header field (Section 3.2) can be used as a precondition |  | The If-Range header field (Section 3.2) can be used as a precondition |
| to applying the Range header field. |  | to applying the Range header field. |
| 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 |
| valid and satisfiable (as defined in Section 2.1), the server SHOULD |  | valid and satisfiable (as defined in Section 2.1), the server SHOULD |
| send a 206 (Partial Content) response with a payload containing one |  | send a 206 (Partial Content) response with a payload containing one |
| or more partial representations that correspond to the satisfiable |  | or more partial representations that correspond to the satisfiable |
| ranges requested, as defined in Section 4. |  | ranges requested, as defined in Section 4. |
| skipping to change at page 9, line 22 |  | skipping to change at page 9, line 22 |
| 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 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 |
| Clients MUST NOT use an entity-tag marked as weak in an If-Range |  | A client MUST NOT generate an If-Range header field containing an |
| field value and MUST NOT use a Last-Modified date in an If-Range |  | entity-tag that is marked as weak. A client MUST NOT generate an If- |
| field value unless it has no entity-tag for the representation and |  | Range header field containing a Last-Modified date unless the client |
| the Last-Modified date it does have for the representation is strong |  | has no entity-tag for the corresponding representation and the Last- |
| in the sense defined by Section 2.2.2 of [Part4]. |  | 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 |  | 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.) |
| 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 |
| skipping to change at page 10, line 4 |  | skipping to change at page 10, line 6 |
| 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. |
| 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, then the server MUST |
| ignore the Range header field. |  | ignore 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 requests'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 |
| range of the selected representation is enclosed, and a payload |  | range of the selected representation is enclosed, and a payload |
| consisting of the range. For example: |  | consisting of the range. For example: |
| HTTP/1.1 206 Partial Content |  | HTTP/1.1 206 Partial Content |
| Date: Wed, 15 Nov 1995 06:25:24 GMT |  | Date: Wed, 15 Nov 1995 06:25:24 GMT |
| Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |  | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
| skipping to change at page 11, line 40 |  | skipping to change at page 11, line 40 |
| parameter length, it can be less efficient to transfer many small |  | parameter length, it can be less efficient to transfer many small |
| disjoint parts than it is to transfer the entire selected |  | disjoint parts than it is to transfer the entire selected |
| representation. |  | representation. |
| A server MUST NOT generate a multipart response to a request for a |  | A server MUST NOT generate a multipart response to a request for a |
| single range, since a client that does not request multiple parts |  | single range, since a client that does not request multiple parts |
| might not support multipart responses. However, a server MAY |  | might not support multipart responses. However, a server MAY |
| generate a multipart/byteranges payload with only a single body part |  | generate a multipart/byteranges payload with only a single body part |
| if multiple ranges were requested and only one range was found to be |  | if multiple ranges were requested and only one range was found to be |
| satisfiable or only one range remained after coalescing. A client |  | satisfiable or only one range remained after coalescing. A client |
| that cannot process a multipart/byteranges response MUST NOT ask for |  | that cannot process a multipart/byteranges response MUST NOT generate |
| multiple ranges in a single request. |  | a request that asks for multiple ranges. |
| When a multipart response payload is generated, the server SHOULD |  | When a multipart response payload is generated, the server SHOULD |
| send the parts in the same order that the corresponding byte-range- |  | send the parts in the same order that the corresponding byte-range- |
| spec appeared in the received Range header field, excluding those |  | spec appeared in the received Range header field, excluding those |
| ranges that were deemed unsatisfiable or that were coalesced into |  | ranges that were deemed unsatisfiable or that were coalesced into |
| other ranges. A client that receives a multipart response MUST |  | other ranges. A client that receives a multipart response MUST |
| inspect the Content-Range header field present in each body part in |  | inspect the Content-Range header field present in each body part in |
| order to determine which range is contained in that body part; a |  | order to determine which range is contained in that body part; a |
| client cannot rely on receiving the same ranges that it requested, |  | client cannot rely on receiving the same ranges that it requested, |
| nor the same order that it requested. |  | nor the same order that it requested. |
| skipping to change at page 14, line 47 |  | skipping to change at page 14, line 47 |
| are 206 responses, then the stored response with the most recent |  | are 206 responses, then the stored response with the most recent |
| header fields is used as the source of header fields for the combined |  | header fields is used as the source of header fields for the combined |
| response, except that the client MUST use other header fields |  | response, except that the client MUST use other header fields |
| provided in the new response, aside from Content-Range, to replace |  | provided in the new response, aside from Content-Range, to replace |
| all instances of the corresponding header fields in the stored |  | all instances of the corresponding header fields in the stored |
| response. |  | response. |
| The combined response message body consists of the union of partial |  | The combined response message body consists of the union of partial |
| content ranges in the new response and each of the selected |  | content ranges in the new response and each of the selected |
| responses. If the union consists of the entire range of the |  | responses. If the union consists of the entire range of the |
| representation, then the client MUST record the combined response as |  | representation, then the client MUST process the combined response as |
| if it were a complete 200 (OK) response, including a Content-Length |  | if it were a complete 200 (OK) response, including a Content-Length |
| header field that reflects the complete length. Otherwise, the |  | header field that reflects the complete length. Otherwise, the |
| client MUST record the set of continuous ranges as one of the |  | client MUST process the set of continuous ranges as one of the |
| following: an incomplete 200 (OK) response if the combined response |  | following: an incomplete 200 (OK) response if the combined response |
| is a prefix of the representation, a single 206 (Partial Content) |  | is a prefix of the representation, a single 206 (Partial Content) |
| response containing a multipart/byteranges body, or multiple 206 |  | response containing a multipart/byteranges body, or multiple 206 |
| (Partial Content) responses, each with one continuous range that is |  | (Partial Content) responses, each with one continuous range that is |
| indicated by a Content-Range header field. |  | indicated by a Content-Range header field. |
| 4.4. 416 Range Not Satisfiable |  | 4.4. 416 Range Not Satisfiable |
| The 416 (Range Not Satisfiable) status code indicates that none of |  | 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 ranges in the request's Range header field (Section 3.1) overlap |
| skipping to change at page 15, line 26 |  | skipping to change at page 15, line 26 |
| For byte ranges, failing to overlap the current extent means that the |  | 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 |  | first-byte-pos of all of the byte-range-spec values were greater than |
| the current length of the selected representation. When this status |  | the current length of the selected representation. When this status |
| code is generated in response to a byte range request, the sender |  | code is generated in response to a byte range request, the sender |
| SHOULD generate a Content-Range header field specifying the current |  | SHOULD generate a Content-Range header field specifying the current |
| length of the selected representation (Section 4.2). |  | length of the selected representation (Section 4.2). |
| For example: |  | For example: |
| HTTP/1.1 416 Range Not Satisfiable |  | HTTP/1.1 416 Range Not Satisfiable |
| Date: Mon, 20 Jan 2012 15:41:54 GMT |  | Date: Fri, 20 Jan 2012 15:41:54 GMT |
| Content-Range: bytes */47022 |  | Content-Range: bytes */47022 |
| Note: Because servers are free to ignore Range, many |  | Note: Because servers are free to ignore Range, many |
| implementations will simply respond with 200 (OK) if the requested |  | implementations will simply respond with the entire selected |
| ranges are invalid or not satisfiable. That is partly because |  | representation in a 200 (OK) response. That is partly because |
| most clients are prepared to receive a 200 (OK) to complete the |  | most clients are prepared to receive a 200 (OK) to complete the |
| task (albeit less efficiently) and partly because clients might |  | task (albeit less efficiently) and partly because clients might |
| not stop making an invalid partial request until they have |  | not stop making an invalid partial request until they have |
| received a complete representation. Thus, clients cannot depend |  | received a complete representation. Thus, clients cannot depend |
| on receiving a 416 (Range Not Satisfiable) response even when it |  | on receiving a 416 (Range Not Satisfiable) response even when it |
| is most appropriate. |  | is most appropriate. |
| 5. IANA Considerations |  | 5. IANA Considerations |
| 5.1. Range Unit Registry |  | 5.1. Range Unit Registry |
| The HTTP Range Unit Registry defines the name space for the range |  | The HTTP Range Unit Registry defines the name space for the range |
| unit names and refers to their corresponding specifications. The |  | unit names and refers to their corresponding specifications. The |
| registry is maintained at |  | registry will be created and maintained at |
| <http://www.iana.org/assignments/http-parameters>. |  | <http://www.iana.org/assignments/http-parameters>. |
| 5.1.1. Procedure |  | 5.1.1. Procedure |
| Registration of an HTTP Range Unit MUST include the following fields: |  | Registration of an HTTP Range Unit MUST include the following fields: |
| o Name |  | o Name |
| o Description |  | o Description |
| skipping to change at page 16, line 46 |  | skipping to change at page 16, line 46 |
| +-------+-----------------------+-------------+ |  | +-------+-----------------------+-------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+-----------------------+-------------+ |  | +-------+-----------------------+-------------+ |
| | 206 | Partial Content | Section 4.1 | |  | | 206 | Partial Content | Section 4.1 | |
| | 416 | Range Not Satisfiable | Section 4.4 | |  | | 416 | Range Not Satisfiable | Section 4.4 | |
| +-------+-----------------------+-------------+ |  | +-------+-----------------------+-------------+ |
| 5.3. Header Field Registration |  | 5.3. Header Field Registration |
| The Message Header Field Registry located at <http://www.iana.org/ |  | HTTP header fields are registered within the Message Header Field |
| assignments/message-headers/message-header-index.html> shall be |  | Registry maintained at <http://www.iana.org/assignments/ |
| updated with the permanent registrations below (see [BCP90]): |  | message-headers/message-header-index.html>. |
|  |  | This document defines the following HTTP header fields, so their |
|  |  | associated registry entries shall be updated according to the |
|  |  | permanent registrations below (see [BCP90]): |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| | Accept-Ranges | http | standard | Section 2.3 | |  | | Accept-Ranges | http | standard | Section 2.3 | |
| | Content-Range | http | standard | Section 4.2 | |  | | Content-Range | http | standard | Section 4.2 | |
| | If-Range | http | standard | Section 3.2 | |  | | If-Range | http | standard | Section 3.2 | |
| | Range | http | standard | Section 3.1 | |  | | Range | http | standard | Section 3.1 | |
| +-------------------+----------+----------+-------------+ |  | +-------------------+----------+----------+-------------+ |
| skipping to change at page 17, line 47 |  | skipping to change at page 17, line 47 |
| 7. Acknowledgments |  | 7. Acknowledgments |
| See Section 9 of [Part1]. |  | See Section 9 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-22 (work in progress), |  | draft-ietf-httpbis-p1-messaging-23 (work in progress), |
| February 2013. |  | July 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-22 (work in progress), |  | draft-ietf-httpbis-p2-semantics-23 (work in progress), |
| February 2013. |  | July 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-22 (work in progress), |  | draft-ietf-httpbis-p4-conditional-23 (work in progress), |
| February 2013. |  | July 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-22 (work in progress), |  | draft-ietf-httpbis-p6-cache-23 (work in progress), |
| February 2013. |  | July 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 19, line 45 |  | skipping to change at page 19, line 45 |
| Macintosh file type code(s): none |  | Macintosh file type code(s): none |
| 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: See Authors Section. |
|  |  | Change controller: IESG |
| Implementation Notes: |  | Implementation Notes: |
| 1. Additional CRLFs might precede the first boundary string in the |  | 1. Additional CRLFs might precede the first boundary string in the |
| body. |  | body. |
| 2. Although [RFC2046] permits the boundary string to be quoted, some |  | 2. Although [RFC2046] permits the boundary string to be quoted, some |
| existing implementations handle a quoted boundary string |  | existing implementations handle a quoted boundary string |
| incorrectly. |  | incorrectly. |
| skipping to change at page 22, line 4 |  | skipping to change at page 21, line 28 |
| OWS = <OWS, defined in [Part1], Section 3.2.3> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| token = <token, defined in [Part1], Section 3.2.6> |  | 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 7.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 |
|  |  | In the collected ABNF below, list rules are expanded as per Section |
|  |  | 1.2 of [Part1]. |
| Accept-Ranges = acceptable-ranges |  | Accept-Ranges = acceptable-ranges |
| Content-Range = byte-content-range / other-content-range |  | Content-Range = byte-content-range / other-content-range |
| HTTP-date = <HTTP-date, defined in [Part2], Section 7.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.3> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| skipping to change at page 23, line 49 |  | skipping to change at page 23, line 49 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security |
| consideration: range flooding" |  | consideration: range flooding" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing |
| heuristic caching for new status codes" |  | heuristic caching for new status codes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add |
| limitations to Range to reduce its use as a denial-of-service |  | limitations to Range to reduce its use as a denial-of-service |
| tool" |  | tool" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/407>: "416 and |
|  |  | multipart/byteranges" |
|  |  | E.4. Since draft-ietf-httpbis-p5-range-22 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list |
|  |  | expansion in ABNF appendices" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/437>: "incorrect |
|  |  | example dates" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type |
|  |  | registration template issues" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/462>: "Editorial |
|  |  | suggestions" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/485>: "MUSTs and |
|  |  | other feedback" |
| 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. 28 change blocks.
| 44 lines changed or deleted |  | 79 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/