| draft-ietf-httpbis-p5-range-20.txt |  | draft-ietf-httpbis-p5-range-21.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 17, 2013 J. Reschke, Ed. |  | Expires: April 7, 2013 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 16, 2012 |  | October 4, 2012 |
| HTTP/1.1, part 5: Range Requests |  | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| draft-ietf-httpbis-p5-range-20 |  | draft-ietf-httpbis-p5-range-21 |
| 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.1. |  | The changes in this draft are summarized in Appendix E.2. |
| 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 17, 2013. |  | This Internet-Draft will expire on April 7, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2012 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 9 |  | skipping to change at page 3, line 9 |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 |  | 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |
| 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 |  | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 |
| 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 |  | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 |
| 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7 |  | 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7 |
| 4.1. Response to a Single and Multiple Ranges Request . . . . . 7 |  | 4.1. Response to a Single and Multiple Ranges Request . . . . . 7 |
| 4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 8 |  | 4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 7 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 |
| 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 |  | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8 |
| 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10 |  | 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 |
| 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
| 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 |  | 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 |
| 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 |  | 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 |
| 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 |  | 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 |
| 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 |  | 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 |
| 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 |  | 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 |
| 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16 |  | 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 |
| 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 |  | Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 19 |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 20 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 19 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 22 |  | publication) . . . . . . . . . . . . . . . . . . . . 22 |
| E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22 |  | E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22 |
|  |  | E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 22 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 canceled requests or dropped connections. When a client has |  | of canceled requests or dropped connections. When a client 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 |
| skipping to change at page 4, line 36 |  | skipping to change at page 4, line 36 |
| Although the HTTP range request mechanism is designed to allow for |  | Although the HTTP range request mechanism is designed to allow for |
| extensible range types, this specification only defines requests for |  | extensible range types, this specification only defines requests for |
| byte ranges. |  | byte ranges. |
| 1.1. Conformance and Error Handling |  | 1.1. Conformance and Error Handling |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| This specification targets conformance criteria according to the role |  | Conformance criteria and considerations regarding error handling are |
| of a participant in HTTP communication. Hence, HTTP requirements are |  | defined in Section 2.5 of [Part1]. |
| placed on senders, recipients, clients, servers, user agents, |  |  |
| intermediaries, origin servers, proxies, gateways, or caches, |  |  |
| depending on what behavior is being constrained by the requirement. |  |  |
| See Section 2 of [Part1] for definitions of these terms. |  |  |
| The verb "generate" is used instead of "send" where a requirement |  |  |
| differentiates between creating a protocol element and merely |  |  |
| forwarding a received element downstream. |  |  |
| An implementation is considered conformant if it complies with all of |  |  |
| the requirements associated with the roles it partakes in HTTP. Note |  |  |
| that SHOULD-level requirements are relevant here, unless one of the |  |  |
| documented exceptions is applicable. |  |  |
| This document also uses ABNF to define valid protocol elements |  |  |
| (Section 1.2). In addition to the prose requirements placed upon |  |  |
| them, senders MUST NOT generate protocol elements that do not match |  |  |
| the grammar defined by the ABNF rules for those protocol elements |  |  |
| that are applicable to the sender's role. If a received protocol |  |  |
| element is processed, the recipient MUST be able to parse any value |  |  |
| that would match the ABNF rules for that protocol element, excluding |  |  |
| only those rules not applicable to the recipient's role. |  |  |
| Unless noted otherwise, a recipient MAY attempt to recover a usable |  |  |
| protocol element from an invalid construct. HTTP does not define |  |  |
| specific error handling mechanisms except when they have a direct |  |  |
| impact on security, since different applications of the protocol |  |  |
| require different error handling strategies. For example, a Web |  |  |
| browser might wish to transparently recover from a response where the |  |  |
| Location header field doesn't parse according to the ABNF, whereas a |  |  |
| systems control client might consider any form of error recovery to |  |  |
| be dangerous. |  |  |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix C describes rules imported from other |  | 1.2 of [Part1]. Appendix C describes rules imported from other |
| documents. Appendix D shows the collected ABNF with the list rule |  | documents. Appendix D shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| 2. Range Units |  | 2. Range Units |
| skipping to change at page 12, line 37 |  | skipping to change at page 12, line 4 |
| representation using a 200 (OK) response. |  | representation using a 200 (OK) response. |
| 5.4. Range |  | 5.4. Range |
| 5.4.1. Byte Ranges |  | 5.4.1. Byte Ranges |
| Since all HTTP representations are transferred as sequences of bytes, |  | Since all HTTP representations are transferred as sequences of bytes, |
| the concept of a byte range is meaningful for any HTTP |  | the concept of a byte range is meaningful for any HTTP |
| representation. (However, not all clients and servers need to |  | representation. (However, not all clients and servers need to |
| support byte-range operations.) |  | support byte-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 representation body (not necessarily the same as the message |  | the representation data (not necessarily the same as the message |
| body). |  | 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 |
| of ranges within a single representation. |  | of 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 |
| skipping to change at page 13, line 16 |  | skipping to change at page 12, line 30 |
| positions specified are inclusive. Byte offsets start at zero. |  | positions specified are inclusive. Byte offsets start at zero. |
| If the last-byte-pos value is present, it MUST be greater than or |  | If the last-byte-pos value is present, it MUST be greater than or |
| equal to the first-byte-pos in that byte-range-spec, or the byte- |  | equal to the first-byte-pos in that byte-range-spec, or the byte- |
| range-spec is syntactically invalid. The recipient of a byte-range- |  | range-spec is syntactically invalid. The recipient of a byte-range- |
| set that includes one or more syntactically invalid byte-range-spec |  | set that includes one or more syntactically invalid byte-range-spec |
| values MUST ignore the header field that includes that byte-range- |  | values MUST ignore the header field that includes that byte-range- |
| set. |  | set. |
| If the last-byte-pos value is absent, or if the value is greater than |  | If the last-byte-pos value is absent, or if the value is greater than |
| or equal to the current length of the representation body, last-byte- |  | or equal to the current length of the representation data, last-byte- |
| pos is taken to be equal to one less than the current length of the |  | pos is taken to be equal to one less than the current length of the |
| representation in bytes. |  | representation in bytes. |
| By its choice of last-byte-pos, a client can limit the number of |  | By its choice of last-byte-pos, a client can limit the number of |
| bytes retrieved without knowing the size of the representation. |  | bytes retrieved without knowing the size of the representation. |
| suffix-byte-range-spec = "-" suffix-length |  | suffix-byte-range-spec = "-" suffix-length |
| suffix-length = 1*DIGIT |  | suffix-length = 1*DIGIT |
| A suffix-byte-range-spec is used to specify the suffix of the |  | A suffix-byte-range-spec is used to specify the suffix of the |
| representation body, of a length given by the suffix-length value. |  | representation data, of a length given by the suffix-length value. |
| (That is, this form specifies the last N bytes of a representation.) |  | (That is, this form specifies the last N bytes of a representation.) |
| If the representation is shorter than the specified suffix-length, |  | If the representation is shorter than the specified suffix-length, |
| the entire representation is used. |  | the entire representation is used. |
| If a syntactically valid byte-range-set includes at least one byte- |  | If a syntactically valid byte-range-set includes at least one byte- |
| range-spec whose first-byte-pos is less than the current length of |  | range-spec whose first-byte-pos is less than the current length of |
| the representation, or at least one suffix-byte-range-spec with a |  | the representation, or at least one suffix-byte-range-spec with a |
| non-zero suffix-length, then the byte-range-set is satisfiable. |  | non-zero suffix-length, then the byte-range-set is satisfiable. |
| Otherwise, the byte-range-set is unsatisfiable. If the byte-range- |  | Otherwise, the byte-range-set is unsatisfiable. If the byte-range- |
| set is unsatisfiable, the server SHOULD return a response with a 416 |  | set is unsatisfiable, the server SHOULD return a response with a 416 |
| skipping to change at page 14, line 35 |  | skipping to change at page 13, line 47 |
| 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 |  | 5.4.2. Range Retrieval Requests |
| The "Range" header field defines the GET method (conditional or not) |  | The "Range" header field defines the GET method (conditional or not) |
| to request one or more sub-ranges of the response representation |  | to request one or more sub-ranges of the response representation |
| body, instead of the entire representation body. |  | data, instead of the entire representation data. |
| Range = byte-ranges-specifier / other-ranges-specifier |  | Range = byte-ranges-specifier / other-ranges-specifier |
| other-ranges-specifier = other-range-unit "=" other-range-set |  | other-ranges-specifier = other-range-unit "=" other-range-set |
| 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 supports efficient partial retrieval of large |  | transfers, and supports efficient partial retrieval of large |
| representations. |  | representations. |
| skipping to change at page 16, line 50 |  | skipping to change at page 16, line 19 |
| the complete resource representation. |  | the complete resource representation. |
| 8. Acknowledgments |  | 8. Acknowledgments |
| See Section 9 of [Part1]. |  | See Section 9 of [Part1]. |
| 9. References |  | 9. References |
| 9.1. Normative References |  | 9.1. Normative References |
| [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 1: Message Routing and Syntax"", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-20 (work in progress), |  | draft-ietf-httpbis-p1-messaging-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 2: Semantics and Payloads", |  | Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-20 (work in progress), |  | draft-ietf-httpbis-p2-semantics-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| "HTTP/1.1, part 4: Conditional Requests", |  | Protocol (HTTP/1.1): Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-20 (work in progress), |  | draft-ietf-httpbis-p4-conditional-21 (work in progress), |
| July 2012. |  | October 2012. |
| [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-20 (work in progress), |  | draft-ietf-httpbis-p6-cache-21 (work in progress), |
| July 2012. |  | October 2012. |
| [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 24 |  | skipping to change at page 19, line 45 |
| x-byteranges, which is almost, but not quite compatible with the |  | x-byteranges, which is almost, but not quite compatible with the |
| version documented in HTTP/1.1. |  | version documented in HTTP/1.1. |
| Appendix B. Changes from RFC 2616 |  | Appendix B. Changes from RFC 2616 |
| Introduce Range Specifier Registry. (Section 2.1) |  | Introduce Range Specifier Registry. (Section 2.1) |
| Clarify that it is not ok to use a weak validator in a 206 response. |  | Clarify that it is not ok to use a weak validator in a 206 response. |
| (Section 3.1) |  | (Section 3.1) |
| Change ABNF productions for header fields to only define the field |  |  |
| value. (Section 5) |  |  |
| Clarify that multipart/byteranges can consist of a single part. |  | Clarify that multipart/byteranges can consist of a single part. |
| (Appendix A) |  | (Appendix A) |
| Appendix C. Imported ABNF |  | Appendix C. Imported ABNF |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
| CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |  | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
| quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any |  | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any |
| 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |  | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| skipping to change at page 20, line 49 |  | skipping to change at page 20, line 18 |
| Note that all rules derived from token are to be compared case- |  | Note that all rules derived from token are to be compared case- |
| insensitively, like range-unit and acceptable-ranges. |  | insensitively, like range-unit and acceptable-ranges. |
| The rules below are defined in [Part1]: |  | The rules below are defined in [Part1]: |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.4> |
| The rules below are defined in other parts: |  | The rules below are defined in other parts: |
| HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> |
| entity-tag = <entity-tag, defined in [Part4], Section 2.3> |  | entity-tag = <entity-tag, defined in [Part4], Section 2.3> |
| Appendix D. Collected ABNF |  | Appendix D. Collected ABNF |
| Accept-Ranges = acceptable-ranges |  | Accept-Ranges = acceptable-ranges |
| Content-Range = byte-content-range-spec / other-content-range-spec |  | Content-Range = byte-content-range-spec / other-content-range-spec |
| HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> |
| If-Range = entity-tag / HTTP-date |  | If-Range = entity-tag / HTTP-date |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| Range = byte-ranges-specifier / other-ranges-specifier |  | Range = byte-ranges-specifier / other-ranges-specifier |
| acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS |  | acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS |
| range-unit ] ) ) / "none" |  | range-unit ] ) ) / "none" |
| skipping to change at page 22, line 30 |  | skipping to change at page 22, line 30 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve |
| 'none' as byte range unit" |  | 'none' as byte range unit" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |
| introduction of new IANA registries as normative changes" |  | introduction of new IANA registries as normative changes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units |
| vs leading zeroes vs size" |  | vs leading zeroes vs size" |
|  |  | E.2. Since draft-ietf-httpbis-p5-range-20 |
|  |  | o Conformance criteria and considerations regarding error handling |
|  |  | are now defined in Part 1. |
| Index |  | Index |
| 2 |  | 2 |
| 206 Partial Content (status code) 6 |  | 206 Partial Content (status code) 5 |
| 4 |  | 4 |
| 416 Requested Range Not Satisfiable (status code) 7 |  | 416 Requested Range Not Satisfiable (status code) 6 |
| A |  | A |
| Accept-Ranges header field 9 |  | Accept-Ranges header field 8 |
| C |  | C |
| Content-Range header field 10 |  | Content-Range header field 9 |
| G |  | G |
| Grammar |  | Grammar |
| Accept-Ranges 9 |  | Accept-Ranges 8 |
| acceptable-ranges 9 |  | acceptable-ranges 8 |
| byte-content-range-spec 10 |  | byte-content-range-spec 9 |
| byte-range-resp-spec 10 |  | byte-range-resp-spec 9 |
| byte-range-set 12 |  | byte-range-set 12 |
| byte-range-spec 12 |  | byte-range-spec 12 |
| byte-ranges-specifier 12 |  | byte-ranges-specifier 12 |
| bytes-unit 5 |  | bytes-unit 5 |
| Content-Range 10 |  | Content-Range 9 |
| first-byte-pos 12 |  | first-byte-pos 12 |
| If-Range 11 |  | If-Range 11 |
| instance-length 10 |  | instance-length 9 |
| last-byte-pos 12 |  | last-byte-pos 12 |
| other-range-unit 5 |  | other-range-unit 5 |
| Range 14 |  | Range 13 |
| range-unit 5 |  | range-unit 5 |
| ranges-specifier 12 |  | ranges-specifier 12 |
| suffix-byte-range-spec 13 |  | suffix-byte-range-spec 12 |
| suffix-length 13 |  | suffix-length 12 |
| H |  |  |
| Header Fields |  |  |
| Accept-Ranges 9 |  |  |
| Content-Range 10 |  |  |
| If-Range 11 |  |  |
| Range 12 |  |  |
| I |  | I |
| If-Range header field 11 |  | If-Range header field 10 |
| M |  | M |
| Media Type |  | Media Type |
| multipart/byteranges 18 |  | multipart/byteranges 17 |
| multipart/x-byteranges 20 |  | multipart/x-byteranges 19 |
| multipart/byteranges Media Type 18 |  | multipart/byteranges Media Type 17 |
| multipart/x-byteranges Media Type 20 |  | multipart/x-byteranges Media Type 19 |
| R |  | R |
| Range header field 12 |  | Range header field 11 |
| S |  |  |
| Status Codes |  |  |
| 206 Partial Content 6 |  |  |
| 416 Requested Range Not Satisfiable 7 |  |  |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 36 change blocks.
| 119 lines changed or deleted |  | 77 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/