| draft-ietf-httpbis-p5-range-01.txt |  | draft-ietf-httpbis-p5-range-02.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Expires: July 15, 2008 J. Mogul |  | Expires: August 27, 2008 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| January 12, 2008 |  | February 24, 2008 |
| HTTP/1.1, part 5: Range Requests and Partial Responses |  | HTTP/1.1, part 5: Range Requests and Partial Responses |
| draft-ietf-httpbis-p5-range-01 |  | draft-ietf-httpbis-p5-range-02 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF), its areas, and its working groups. Note that |
| skipping to change at page 1, line 49 |  | skipping to change at page 1, line 49 |
| 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." |
| The list of current Internet-Drafts can be accessed at |  | The list of current Internet-Drafts can be accessed at |
| http://www.ietf.org/ietf/1id-abstracts.txt. |  | http://www.ietf.org/ietf/1id-abstracts.txt. |
| The list of Internet-Draft Shadow Directories can be accessed at |  | The list of Internet-Draft Shadow Directories can be accessed at |
| http://www.ietf.org/shadow.html. |  | http://www.ietf.org/shadow.html. |
| This Internet-Draft will expire on July 15, 2008. |  | This Internet-Draft will expire on August 27, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2008). |  | Copyright (C) The IETF Trust (2008). |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| skipping to change at page 3, line 9 |  | skipping to change at page 3, line 9 |
| This draft incorporates those issue resolutions that were either |  | This draft incorporates those issue resolutions that were either |
| collected in the original RFC2616 errata list |  | collected in the original RFC2616 errata list |
| (<http://purl.org/NET/http-errata>), or which were agreed upon on the |  | (<http://purl.org/NET/http-errata>), or which were agreed upon on the |
| mailing list between October 2006 and November 2007 (as published in |  | mailing list between October 2006 and November 2007 (as published in |
| "draft-lafon-rfc2616bis-03"). |  | "draft-lafon-rfc2616bis-03"). |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 3. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 |  | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 |  | 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 |
| 4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6 |  | 4.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6 |  | 5. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6 |
| 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 |
| 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7 |  | 6.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |
| 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 6.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 |
| 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 6.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 10 |  | 6.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12 |  | 6.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 10 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |  | 6.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |
|  |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 14 |  | Appendix A. Internet Media Type multipart/byteranges . . . . . . 14 |
| Appendix B. Compatibility with Previous Versions . . . . . . . . 15 |  | Appendix B. Compatibility with Previous Versions . . . . . . . . 16 |
| B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 15 |  | B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 16 |
| B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 16 |  | B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 16 |  | publication) . . . . . . . . . . . . . . . . . . . . 17 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 16 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17 |
| C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 16 |  | C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 17 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | C.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 17 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 21 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 22 |
| 1. Introduction |  | 1. Introduction |
| HTTP clients often encounter interrupted data transfers as a result |  | HTTP clients often encounter interrupted data transfers as a result |
| of cancelled requests or dropped connections. When a cache has |  | of cancelled requests or dropped connections. When a cache has |
| stored a partial representation, it is desirable to request the |  | stored a partial representation, it is desirable to request the |
| remainder of that representation in a subsequent request rather than |  | remainder of that representation in a subsequent request rather than |
| transfer the entire representation. There are also a number of Web |  | transfer the entire representation. There are also a number of Web |
| applications that benefit from being able to request only a subset of |  | applications that benefit from being able to request only a subset of |
| a larger representation, such as a single page of a very large |  | a larger representation, such as a single page of a very large |
| skipping to change at page 4, line 45 |  | skipping to change at page 4, line 45 |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the MUST or REQUIRED level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the MUST or |
| REQUIRED level and all the SHOULD level requirements for its |  | REQUIRED level and all the SHOULD level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the MUST level requirements but not all the SHOULD |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant." |
| 2. Range Units |  | 2. Notational Conventions and Generic Grammar |
|  |  | This specification uses the ABNF syntax defined in Section 2.1 of |
|  |  | [Part1] and the core rules defined in Section 2.2 of [Part1]: |
|  |  | [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC |
|  |  | 5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]] |
|  |  | DIGIT = <DIGIT, defined in [Part1], Section 2.2> |
|  |  | SP = <SP, defined in [Part1], Section 2.2> |
|  |  | token = <token, defined in [Part1], Section 2.2> |
|  |  | The ABNF rules below are defined in other parts: |
|  |  | HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> |
|  |  | entity-tag = <entity-tag, defined in [Part4], Section 3> |
|  |  | 3. Range Units |
| HTTP/1.1 allows a client to request that only part (a range of) the |  | HTTP/1.1 allows a client to request that only part (a range of) the |
| response entity be included within the response. HTTP/1.1 uses range |  | response entity be included within the response. HTTP/1.1 uses range |
| units in the Range (Section 5.4) and Content-Range (Section 5.2) |  | units in the Range (Section 6.4) and Content-Range (Section 6.2) |
| header fields. An entity can be broken down into subranges according |  | header fields. An entity can be broken down into subranges according |
| to various structural units. |  | to various structural units. |
| range-unit = bytes-unit | other-range-unit |  | range-unit = bytes-unit | other-range-unit |
| bytes-unit = "bytes" |  | bytes-unit = "bytes" |
| other-range-unit = token |  | other-range-unit = token |
| The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |  | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |
| implementations MAY ignore ranges specified using other units. |  | implementations MAY ignore ranges specified using other units. |
| HTTP/1.1 has been designed to allow implementations of applications |  | HTTP/1.1 has been designed to allow implementations of applications |
| that do not depend on knowledge of ranges. |  | that do not depend on knowledge of ranges. |
| 3. Status Code Definitions |  | 4. Status Code Definitions |
| 3.1. 206 Partial Content |  | 4.1. 206 Partial Content |
| The server has fulfilled the partial GET request for the resource. |  | The server has fulfilled the partial GET request for the resource. |
| The request MUST have included a Range header field (Section 5.4) |  | The request MUST have included a Range header field (Section 6.4) |
| indicating the desired range, and MAY have included an If-Range |  | indicating the desired range, and MAY have included an If-Range |
| header field (Section 5.3) to make the request conditional. |  | header field (Section 6.3) to make the request conditional. |
| The response MUST include the following header fields: |  | The response MUST include the following header fields: |
| o Either a Content-Range header field (Section 5.2) indicating the |  | o Either a Content-Range header field (Section 6.2) indicating the |
| range included with this response, or a multipart/byteranges |  | range included with this response, or a multipart/byteranges |
| Content-Type including Content-Range fields for each part. If a |  | Content-Type including Content-Range fields for each part. If a |
| Content-Length header field is present in the response, its value |  | Content-Length header field is present in the response, its value |
| MUST match the actual number of OCTETs transmitted in the message- |  | MUST match the actual number of OCTETs transmitted in the message- |
| body. |  | body. |
| o Date |  | o Date |
| o ETag and/or Content-Location, if the header would have been sent |  | o ETag and/or Content-Location, if the header would have been sent |
| in a 200 response to the same request |  | in a 200 response to the same request |
| skipping to change at page 5, line 49 |  | skipping to change at page 6, line 23 |
| differ from that sent in any previous response for the same |  | differ from that sent in any previous response for the same |
| variant |  | variant |
| If the 206 response is the result of an If-Range request, the |  | If the 206 response is the result of an If-Range request, the |
| response SHOULD NOT include other entity-headers. Otherwise, the |  | response SHOULD NOT include other entity-headers. Otherwise, the |
| response MUST include all of the entity-headers that would have been |  | response MUST include all of the entity-headers that would have been |
| returned with a 200 (OK) response to the same request. |  | returned with a 200 (OK) response to the same request. |
| A cache MUST NOT combine a 206 response with other previously cached |  | A cache MUST NOT combine a 206 response with other previously cached |
| content if the ETag or Last-Modified headers do not match exactly, |  | content if the ETag or Last-Modified headers do not match exactly, |
| see Section 4. |  | see Section 5. |
| A cache that does not support the Range and Content-Range headers |  | A cache that does not support the Range and Content-Range headers |
| MUST NOT cache 206 (Partial Content) responses. |  | MUST NOT cache 206 (Partial Content) responses. |
| 3.2. 416 Requested Range Not Satisfiable |  | 4.2. 416 Requested Range Not Satisfiable |
| A server SHOULD return a response with this status code if a request |  | A server SHOULD return a response with this status code if a request |
| included a Range request-header field (Section 5.4), and none of the |  | included a Range request-header field (Section 6.4), and none of the |
| range-specifier values in this field overlap the current extent of |  | range-specifier values in this field overlap the current extent of |
| the selected resource, and the request did not include an If-Range |  | the selected resource, and the request did not include an If-Range |
| request-header field. (For byte-ranges, this means that the first- |  | request-header field. (For byte-ranges, this means that the first- |
| byte-pos of all of the byte-range-spec values were greater than the |  | byte-pos of all of the byte-range-spec values were greater than the |
| current length of the selected resource.) |  | current length of the selected resource.) |
| When this status code is returned for a byte-range request, the |  | When this status code is returned for a byte-range request, the |
| response SHOULD include a Content-Range entity-header field |  | response SHOULD include a Content-Range entity-header field |
| specifying the current length of the selected resource (see |  | specifying the current length of the selected resource (see |
| Section 5.2). This response MUST NOT use the multipart/byteranges |  | Section 6.2). This response MUST NOT use the multipart/byteranges |
| content-type. |  | content-type. |
| 4. Combining Byte Ranges |  | 5. Combining Byte Ranges |
| A response might transfer only a subrange of the bytes of an entity- |  | A response might transfer only a subrange of the bytes of an entity- |
| body, either because the request included one or more Range |  | body, either because the request included one or more Range |
| specifications, or because a connection was broken prematurely. |  | specifications, or because a connection was broken prematurely. |
| After several such transfers, a cache might have received several |  | After several such transfers, a cache might have received several |
| ranges of the same entity-body. |  | ranges of the same entity-body. |
| If a cache has a stored non-empty set of subranges for an entity, and |  | If a cache has a stored non-empty set of subranges for an entity, and |
| an incoming response transfers another subrange, the cache MAY |  | an incoming response transfers another subrange, the cache MAY |
| combine the new subrange with the existing set if both the following |  | combine the new subrange with the existing set if both the following |
| conditions are met: |  | conditions are met: |
| o Both the incoming response and the cache entry have a cache |  | o Both the incoming response and the cache entry have a cache |
| validator. |  | validator. |
| o The two cache validators match using the strong comparison |  | o The two cache validators match using the strong comparison |
| function (see Section 4 of [Part4]). |  | function (see Section 5 of [Part4]). |
| If either requirement is not met, the cache MUST use only the most |  | If either requirement is not met, the cache MUST use only the most |
| recent partial response (based on the Date values transmitted with |  | recent partial response (based on the Date values transmitted with |
| every response, and using the incoming response if these values are |  | every response, and using the incoming response if these values are |
| equal or missing), and MUST discard the other partial information. |  | equal or missing), and MUST discard the other partial information. |
| 5. Header Field Definitions |  | 6. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to range requests and partial responses. |  | fields related to range requests and partial responses. |
| For entity-header fields, both sender and recipient refer to either |  | For entity-header fields, both sender and recipient refer to either |
| the client or the server, depending on who sends and who receives the |  | the client or the server, depending on who sends and who receives the |
| entity. |  | entity. |
| 5.1. Accept-Ranges |  | 6.1. Accept-Ranges |
| The Accept-Ranges response-header field allows the server to indicate |  | The Accept-Ranges response-header field allows the server to indicate |
| its acceptance of range requests for a resource: |  | its acceptance of range requests for a resource: |
| Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges |  | Accept-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 accept byte-range requests MAY send |
| Accept-Ranges: bytes |  | Accept-Ranges: bytes |
| but are not required to do so. Clients MAY generate byte-range |  | but are not required to do so. Clients MAY generate byte-range |
| requests without having received this header for the resource |  | requests without having received this header for the resource |
| involved. Range units are defined in Section 2. |  | involved. Range units are defined in Section 3. |
| Servers that do not accept any kind of range request for a resource |  | Servers that do not accept any kind of range request for a resource |
| MAY send |  | 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 |  | 6.2. Content-Range |
| The Content-Range entity-header is sent with a partial entity-body to |  | The Content-Range entity-header is sent with a partial entity-body to |
| specify where in the full entity-body the partial body should be |  | specify where in the full entity-body the partial body should be |
| applied. Range units are defined in Section 2. |  | applied. Range units are defined in Section 3. |
| Content-Range = "Content-Range" ":" content-range-spec |  | Content-Range = "Content-Range" ":" content-range-spec |
| content-range-spec = byte-content-range-spec |  | content-range-spec = byte-content-range-spec |
| byte-content-range-spec = bytes-unit SP |  | byte-content-range-spec = bytes-unit SP |
| byte-range-resp-spec "/" |  | byte-range-resp-spec "/" |
| ( instance-length | "*" ) |  | ( instance-length | "*" ) |
| byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) |  | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) |
| | "*" |  | | "*" |
| instance-length = 1*DIGIT |  | instance-length = 1*DIGIT |
| The header SHOULD indicate the total length of the full entity-body, |  | The header SHOULD indicate the total length of the full entity-body, |
| unless this length is unknown or difficult to determine. The |  | unless this length is unknown or difficult to determine. The |
| asterisk "*" character means that the instance-length is unknown at |  | asterisk "*" character means that the instance-length is unknown at |
| the time when the response was generated. |  | the time when the response was generated. |
| Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- |  | Unlike byte-ranges-specifier values (see Section 6.4.1), a byte- |
| range-resp-spec MUST only specify one range, and MUST contain |  | range-resp-spec MUST only specify one range, and MUST contain |
| absolute byte positions for both the first and last byte of the |  | absolute byte positions for both the first and last byte of the |
| range. |  | range. |
| A byte-content-range-spec with a byte-range-resp-spec whose last- |  | 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 |  | 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 |  | instance-length value is less than or equal to its last-byte-pos |
| value, is invalid. The recipient of an invalid byte-content-range- |  | value, is invalid. The recipient of an invalid byte-content-range- |
| spec MUST ignore it and any content transferred along with it. |  | spec MUST ignore it and any content transferred along with it. |
| skipping to change at page 9, line 33 |  | skipping to change at page 10, line 8 |
| If the server ignores a byte-range-spec because it is syntactically |  | If the server ignores a byte-range-spec because it is syntactically |
| invalid, the server SHOULD treat the request as if the invalid Range |  | invalid, the server SHOULD treat the request as if the invalid Range |
| header field did not exist. (Normally, this means return a 200 |  | header field did not exist. (Normally, this means return a 200 |
| response containing the full entity). |  | response containing the full entity). |
| If the server receives a request (other than one including an If- |  | If the server receives a request (other than one including an If- |
| Range request-header field) with an unsatisfiable Range request- |  | Range request-header field) with an unsatisfiable Range request- |
| header field (that is, all of whose byte-range-spec values have a |  | header field (that is, all of whose byte-range-spec values have a |
| first-byte-pos value greater than the current length of the selected |  | first-byte-pos value greater than the current length of the selected |
| resource), it SHOULD return a response code of 416 (Requested range |  | resource), it SHOULD return a response code of 416 (Requested range |
| not satisfiable) (Section 3.2). |  | not satisfiable) (Section 4.2). |
| Note: clients cannot depend on servers to send a 416 (Requested |  | Note: clients cannot depend on servers to send a 416 (Requested |
| range not satisfiable) response instead of a 200 (OK) response for |  | range not satisfiable) response instead of a 200 (OK) response for |
| an unsatisfiable Range request-header, since not all servers |  | an unsatisfiable Range request-header, since not all servers |
| implement this request-header. |  | implement this request-header. |
| 5.3. If-Range |  | 6.3. If-Range |
| If a client has a partial copy of an entity in its cache, and wishes |  | If a client has a partial copy of an entity in its cache, and wishes |
| to have an up-to-date copy of the entire entity in its cache, it |  | to have an up-to-date copy of the entire entity in its cache, it |
| could use the Range request-header with a conditional GET (using |  | could use the Range request-header with a conditional GET (using |
| either or both of If-Unmodified-Since and If-Match.) However, if the |  | either or both of If-Unmodified-Since and If-Match.) However, if the |
| condition fails because the entity has been modified, the client |  | condition fails because the entity has been modified, the client |
| would then have to make a second request to obtain the entire current |  | would then have to make a second request to obtain the entire current |
| entity-body. |  | entity-body. |
| The If-Range header allows a client to "short-circuit" the second |  | The If-Range header allows a client to "short-circuit" the second |
| skipping to change at page 10, line 23 |  | skipping to change at page 10, line 46 |
| header SHOULD only be used together with a Range header, and MUST be |  | header SHOULD only be used together with a Range header, and MUST be |
| ignored if the request does not include a Range header, or if the |  | ignored if the request does not include a Range header, or if the |
| server does not support the sub-range operation. |  | server does not support the sub-range operation. |
| If the entity tag given in the If-Range header matches the current |  | If the entity tag given in the If-Range header matches the current |
| entity tag for the entity, then the server SHOULD provide the |  | entity tag for the entity, then the server SHOULD provide the |
| specified sub-range of the entity using a 206 (Partial Content) |  | specified sub-range of the entity using a 206 (Partial Content) |
| response. If the entity tag does not match, then the server SHOULD |  | response. If the entity tag does not match, then the server SHOULD |
| return the entire entity using a 200 (OK) response. |  | return the entire entity using a 200 (OK) response. |
| 5.4. Range |  | 6.4. Range |
| 5.4.1. Byte Ranges |  | 6.4.1. Byte Ranges |
| Since all HTTP entities are represented in HTTP messages as sequences |  | Since all HTTP entities are represented in HTTP messages as sequences |
| of bytes, the concept of a byte range is meaningful for any HTTP |  | of bytes, the concept of a byte range is meaningful for any HTTP |
| entity. (However, not all clients and servers need to support byte- |  | entity. (However, not all clients and servers need to support byte- |
| range operations.) |  | range operations.) |
| Byte range specifications in HTTP apply to the sequence of bytes in |  | Byte range specifications in HTTP apply to the sequence of bytes in |
| the entity-body (not necessarily the same as the message-body). |  | the entity-body (not necessarily the same as the message-body). |
| A byte range operation MAY specify a single range of bytes, or a set |  | A byte range operation MAY specify a single range of bytes, or a set |
| skipping to change at page 12, line 4 |  | skipping to change at page 12, line 25 |
| o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- |  | o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- |
| 999 |  | 999 |
| o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- |  | o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- |
| 500 |  | 500 |
| o Or bytes=9500- |  | o Or bytes=9500- |
| o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 |  | o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 |
| o Several legal but not canonical specifications of the second 500 |  | o Several legal but not canonical specifications of the second 500 |
| bytes (byte offsets 500-999, inclusive): |  | bytes (byte offsets 500-999, inclusive): |
| bytes=500-600,601-999 |  | bytes=500-600,601-999 |
| bytes=500-700,601-999 |  | bytes=500-700,601-999 |
| 5.4.2. Range Retrieval Requests |  | 6.4.2. Range Retrieval Requests |
| HTTP retrieval requests using conditional or unconditional GET |  | HTTP retrieval requests using conditional or unconditional GET |
| methods MAY request one or more sub-ranges of the entity, instead of |  | methods MAY request one or more sub-ranges of the entity, instead of |
| the entire entity, using the Range request header, which applies to |  | the entire entity, using the Range request header, which applies to |
| the entity returned as the result of the request: |  | the entity returned as the result of the request: |
| Range = "Range" ":" ranges-specifier |  | Range = "Range" ":" ranges-specifier |
| A server MAY ignore the Range header. However, HTTP/1.1 origin |  | A server MAY ignore the Range header. However, HTTP/1.1 origin |
| servers and intermediate caches ought to support byte ranges when |  | servers and intermediate caches ought to support byte ranges when |
| skipping to change at page 12, line 40 |  | skipping to change at page 13, line 14 |
| instead of 200 (OK). |  | instead of 200 (OK). |
| o The presence of a Range header in a conditional GET (a request |  | o The presence of a Range header in a conditional GET (a request |
| using one or both of If-Modified-Since and If-None-Match, or one |  | 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 |  | or both of If-Unmodified-Since and If-Match) modifies what is |
| returned if the GET is otherwise successful and the condition is |  | returned if the GET is otherwise successful and the condition is |
| true. It does not affect the 304 (Not Modified) response returned |  | true. It does not affect the 304 (Not Modified) response returned |
| if the conditional is false. |  | if the conditional is false. |
| In some cases, it might be more appropriate to use the If-Range |  | In some cases, it might be more appropriate to use the If-Range |
| header (see Section 5.3) in addition to the Range header. |  | header (see Section 6.3) in addition to the Range header. |
| If a proxy that supports ranges receives a Range request, forwards |  | If a proxy that supports ranges receives a Range request, forwards |
| the request to an inbound server, and receives an entire entity in |  | the request to an inbound server, and receives an entire entity in |
| reply, it SHOULD only return the requested range to its client. It |  | reply, it SHOULD only return the requested range to its client. It |
| SHOULD store the entire received response in its cache if that is |  | SHOULD store the entire received response in its cache if that is |
| consistent with its cache allocation policies. |  | consistent with its cache allocation policies. |
| 6. IANA Considerations |  | 7. IANA Considerations |
| TBD. |  | [[anchor2: TBD.]] |
| 7. Security Considerations |  | 8. Security Considerations |
| No additional security considerations have been identified beyond |  | No additional security considerations have been identified beyond |
| those applicable to HTTP in general [Part1]. |  | those applicable to HTTP in general [Part1]. |
| 8. Acknowledgments |  | 9. Acknowledgments |
| Most of the specification of ranges is based on work originally done |  | Most of the specification of ranges is based on work originally done |
| by Ari Luotonen and John Franks, with additional input from Steve |  | by Ari Luotonen and John Franks, with additional input from Steve |
| Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin |  | Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin |
| Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, |  | Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, |
| Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi |  | Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi |
| Rizzo, and Bill Weihl. |  | Rizzo, and Bill Weihl. |
| 9. References |  | 10. References |
| 9.1. Normative References |  | 10.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-01 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-02 |
| (work in progress), January 2008. |  | (work in progress), February 2008. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-01 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-02 |
| (work in progress), January 2008. |  | (work in progress), February 2008. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| Requests", draft-ietf-httpbis-p4-conditional-01 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-02 (work in |
| progress), January 2008. |  | progress), February 2008. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-01 (work in progress), |  | draft-ietf-httpbis-p6-cache-02 (work in progress), |
| January 2008. |  | February 2008. |
| [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. |
| 9.2. Informative References |  | 10.2. Informative References |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
|  |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
|  |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
| 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 an HTTP 206 (Partial Content) response message includes the |
| content of multiple ranges (a response to a request for multiple non- |  | content of multiple ranges (a response to a request for multiple non- |
| overlapping ranges), these are transmitted as a multipart message- |  | overlapping ranges), these are transmitted as a multipart message- |
| body. The media type for this purpose is called "multipart/ |  | body [RFC2046]. The media type for this purpose is called |
| byteranges". |  | "multipart/byteranges". The following is to be registered with IANA |
|  |  | [RFC4288]. |
| The multipart/byteranges media type includes two or more parts, each |  | The multipart/byteranges media type includes two or more parts, each |
| with its own Content-Type and Content-Range fields. The required |  | with its own Content-Type and Content-Range fields. The required |
| boundary parameter specifies the boundary string used to separate |  | boundary parameter specifies the boundary string used to separate |
| each body-part. |  | each body-part. |
| Media Type name: multipart |  | Type name: multipart |
| Media 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 |
| permitted |  | permitted |
| Security considerations: none |  | Security considerations: none |
|  |  | Interoperability considerations: none |
|  |  | Published specification: This specification (see Appendix A). |
|  |  | Applications that use this media type: |
|  |  | Additional information: |
|  |  | Magic number(s): none |
|  |  | File extension(s): none |
|  |  | Macintosh file type code(s): none |
|  |  | Person and email address to contact for further information: See |
|  |  | Authors Section. |
|  |  | Intended usage: COMMON |
|  |  | Restrictions on usage: none |
|  |  | Author/Change controller: IESG |
| For example: |  | 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 |
| Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |  | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
| --THIS_STRING_SEPARATES |  | --THIS_STRING_SEPARATES |
| Content-type: application/pdf |  | Content-type: application/pdf |
| Content-range: bytes 500-999/8000 |  | Content-range: bytes 500-999/8000 |
| skipping to change at page 15, line 45 |  | skipping to change at page 16, line 45 |
| version documented in HTTP/1.1. |  | version documented in HTTP/1.1. |
| Appendix B. Compatibility with Previous Versions |  | Appendix B. Compatibility with Previous Versions |
| B.1. Changes from RFC 2068 |  | B.1. Changes from RFC 2068 |
| Transfer-coding and message lengths all interact in ways that |  | Transfer-coding and message lengths all interact in ways that |
| required fixing exactly when chunked encoding is used (to allow for |  | required fixing exactly when chunked encoding is used (to allow for |
| transfer encoding that may not be self delimiting); it was important |  | transfer encoding that may not be self delimiting); it was important |
| to straighten out exactly how message lengths are computed. |  | to straighten out exactly how message lengths are computed. |
| (Section 5.2, see also [Part1], [Part3] and [Part6]) |  | (Section 6.2, see also [Part1], [Part3] and [Part6]) |
| There are situations where a server (especially a proxy) does not |  | There are situations where a server (especially a proxy) does not |
| know the full length of a response but is capable of serving a |  | know the full length of a response but is capable of serving a |
| byterange request. We therefore need a mechanism to allow byteranges |  | byterange request. We therefore need a mechanism to allow byteranges |
| with a content-range not indicating the full length of the message. |  | with a content-range not indicating the full length of the message. |
| (Section 5.2) |  | (Section 6.2) |
| Range request responses would become very verbose if all meta-data |  | Range request responses would become very verbose if all meta-data |
| were always returned; by allowing the server to only send needed |  | were always returned; by allowing the server to only send needed |
| headers in a 206 response, this problem can be avoided. (Section 3.1 |  | headers in a 206 response, this problem can be avoided. (Section 4.1 |
| and 5.3) |  | and 6.3) |
| Fix problem with unsatisfiable range requests; there are two cases: |  | Fix problem with unsatisfiable range requests; there are two cases: |
| syntactic problems, and range doesn't exist in the document. The 416 |  | syntactic problems, and range doesn't exist in the document. The 416 |
| status code was needed to resolve this ambiguity needed to indicate |  | status code was needed to resolve this ambiguity needed to indicate |
| an error for a byte range request that falls outside of the actual |  | an error for a byte range request that falls outside of the actual |
| contents of a document. (Section 3.2, 5.2) |  | contents of a document. (Section 4.2, 6.2) |
| B.2. Changes from RFC 2616 |  | B.2. Changes from RFC 2616 |
| Clarify that it is not ok to use a weak cache validator in a 206 |  | Clarify that it is not ok to use a weak cache validator in a 206 |
| response. (Section 3.1) |  | response. (Section 4.1) |
| Appendix C. Change Log (to be removed by RFC Editor before publication) |  | Appendix C. Change Log (to be removed by RFC Editor before publication) |
| C.1. Since RFC2616 |  | C.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| C.2. Since draft-ietf-httpbis-p5-range-00 |  | C.2. Since draft-ietf-httpbis-p5-range-00 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 16, line 43 |  | skipping to change at page 17, line 43 |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache |
| validators in 206 responses" |  | validators in 206 responses" |
| (<http://purl.org/NET/http-errata#ifrange206>) |  | (<http://purl.org/NET/http-errata#ifrange206>) |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |
| and Informative references" |  | and Informative references" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative |
| up-to-date references" |  | up-to-date references" |
|  |  | C.3. Since draft-ietf-httpbis-p5-range-01 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating |
|  |  | to RFC4288" |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Add explicit references to BNF syntax and rules imported from |
|  |  | other parts of the specification. |
| Index |  | Index |
| 2 |  | 2 |
| 206 Partial Content (status code) 5 |  | 206 Partial Content (status code) 5 |
| 4 |  | 4 |
| 416 Requested Range Not Satisfiable (status code) 6 |  | 416 Requested Range Not Satisfiable (status code) 6 |
| A |  | A |
| Accept-Ranges header 7 |  | Accept-Ranges header 7 |
| C |  | C |
| Content-Range header 7 |  | Content-Range header 8 |
| G |  | G |
| Grammar |  | Grammar |
| Accept-Ranges 7 |  | Accept-Ranges 7 |
| acceptable-ranges 7 |  | acceptable-ranges 7 |
| byte-content-range-spec 7 |  | byte-content-range-spec 8 |
| byte-range-resp-spec 7 |  | byte-range-resp-spec 8 |
| byte-range-set 10 |  | byte-range-set 11 |
| byte-range-spec 10 |  | byte-range-spec 11 |
| byte-ranges-specifier 10 |  | byte-ranges-specifier 11 |
| bytes-unit 5 |  | bytes-unit 5 |
| Content-Range 7 |  | Content-Range 8 |
| content-range-spec 7 |  | content-range-spec 8 |
| first-byte-pos 10 |  | first-byte-pos 11 |
| If-Range 10 |  | If-Range 10 |
| instance-length 7 |  | instance-length 8 |
| last-byte-pos 10 |  | last-byte-pos 11 |
| other-range-unit 5 |  | other-range-unit 5 |
| Range 12 |  | Range 12 |
| range-unit 5 |  | range-unit 5 |
| ranges-specifier 10 |  | ranges-specifier 11 |
| suffix-byte-range-spec 11 |  | suffix-byte-range-spec 11 |
| suffix-length 11 |  | suffix-length 11 |
| H |  | H |
| Headers |  | Headers |
| Accept-Ranges 7 |  | Accept-Ranges 7 |
| Content-Range 7 |  | Content-Range 8 |
| If-Range 9 |  | If-Range 10 |
| Range 10 |  | Range 10 |
| I |  | I |
| If-Range header 9 |  | If-Range header 10 |
| M |  | M |
| Media Type |  | Media Type |
| multipart/byteranges 14 |  | multipart/byteranges 14 |
| multipart/x-byteranges 15 |  | multipart/x-byteranges 16 |
| multipart/byteranges Media Type 14 |  | multipart/byteranges Media Type 14 |
| multipart/x-byteranges Media Type 15 |  | multipart/x-byteranges Media Type 16 |
| R |  | R |
| Range header 10 |  | Range header 10 |
| S |  | S |
| Status Codes |  | Status Codes |
| 206 Partial Content 5 |  | 206 Partial Content 5 |
| 416 Requested Range Not Satisfiable 6 |  | 416 Requested Range Not Satisfiable 6 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
End of changes. 67 change blocks.
| 99 lines changed or deleted |  | 160 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/