| draft-ietf-httpbis-p5-range-19.txt |  | draft-ietf-httpbis-p5-range-20.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: September 13, 2012 J. Reschke, Ed. |  | Expires: January 17, 2013 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| March 12, 2012 |  | July 16, 2012 |
| HTTP/1.1, part 5: Range Requests and Partial Responses |  | HTTP/1.1, part 5: Range Requests |
| draft-ietf-httpbis-p5-range-19 |  | draft-ietf-httpbis-p5-range-20 |
| 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. HTTP has been in use by the World Wide Web global |  | systems. This document defines range requests and the rules for |
| information initiative since 1990. This document is Part 5 of the |  | constructing and combining responses to those requests. |
| seven-part specification that defines the protocol referred to as |  |  |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. |  |  |
| Part 5 defines range-specific requests and the rules for 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 should take place on the HTTPBIS working |  | Discussion of this draft takes place on the HTTPBIS working group |
| 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 D.20. |  | The changes in this draft are summarized in Appendix E.1. |
| 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 September 13, 2012. |  | This Internet-Draft will expire on January 17, 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 2, line 42 |  | skipping to change at page 3, line 10 |
| 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 . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |  |  |
| 1.2.2. ABNF Rules defined in other Parts of the |  |  |
| Specification . . . . . . . . . . . . . . . . . . . . 5 |  |  |
| 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 |  | 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 |
| 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 |  | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 |
| 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 |  | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 |
| 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 . . . . . . . . . . . . . . . . . . . . . 8 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |
| 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 |  | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 |
| skipping to change at page 3, line 22 |  | skipping to change at page 3, line 35 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |
| 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 |  | 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 |
| 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 |  | 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 |
| 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 |  | 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 |
| 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 . . . . . . . . . . . . . . . . . . 17 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 |  | Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |  | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |  | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 20 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |
|  |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 22 |  | publication) . . . . . . . . . . . . . . . . . . . . 22 |
| D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 |  | E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22 |
| D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
| D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 |  |  |
| D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 |  |  |
| D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23 |  |  |
| D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23 |  |  |
| D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23 |  |  |
| D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 |  |  |
| D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24 |  |  |
| D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24 |  |  |
| D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24 |  |  |
| D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24 |  |  |
| D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24 |  |  |
| D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25 |  |  |
| D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25 |  |  |
| D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25 |  |  |
| D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25 |  |  |
| D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 25 |  |  |
| D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 25 |  |  |
| D.20. Since draft-ietf-httpbis-p5-range-18 . . . . . . . . . . . 25 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  |  |
| 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 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 |
| a larger representation, such as a single page of a very large |  | a larger representation, such as a single page of a very large |
| document or only part of an image to be rendered by a device with |  | document or only part of an image to be rendered by a device with |
| limited local storage. |  | limited local storage. |
| This document defines HTTP/1.1 range requests, partial responses, and |  | This document defines HTTP/1.1 range requests, partial responses, and |
| the multipart/byteranges media type. The protocol for range requests |  | the multipart/byteranges media type. The protocol for range requests |
| 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 document defines conformance criteria for several roles in HTTP |  | This specification targets conformance criteria according to the role |
| communication, including Senders, Recipients, Clients, Servers, User- |  | of a participant in HTTP communication. Hence, HTTP requirements are |
| Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |  | placed on senders, recipients, clients, servers, user agents, |
| Section 2 of [Part1] for definitions of these terms. |  | 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 |  | An implementation is considered conformant if it complies with all of |
| the requirements associated with its role(s). Note that SHOULD-level |  | the requirements associated with the roles it partakes in HTTP. Note |
| requirements are relevant here, unless one of the documented |  | that SHOULD-level requirements are relevant here, unless one of the |
| exceptions is applicable. |  | documented exceptions is applicable. |
| This document also uses ABNF to define valid protocol elements |  | This document also uses ABNF to define valid protocol elements |
| (Section 1.2). In addition to the prose requirements placed upon |  | (Section 1.2). In addition to the prose requirements placed upon |
| them, Senders MUST NOT generate protocol elements that are invalid. |  | 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, Recipients MAY take steps to recover a usable |  | Unless noted otherwise, a recipient MAY attempt to recover a usable |
| protocol element from an invalid construct. However, HTTP does not |  | protocol element from an invalid construct. HTTP does not define |
| define specific error handling mechanisms, except in cases where it |  | specific error handling mechanisms except when they have a direct |
| has direct impact on security. This is because different uses of the |  | impact on security, since different applications of the protocol |
| protocol require different error handling strategies; for example, a |  | require different error handling strategies. For example, a Web |
| Web browser may wish to transparently recover from a response where |  | browser might wish to transparently recover from a response where the |
| the Location header field doesn't parse according to the ABNF, |  | Location header field doesn't parse according to the ABNF, whereas a |
| whereby in a systems control protocol using HTTP, this type of error |  | systems control client might consider any form of error recovery to |
| recovery could lead to dangerous consequences. |  | 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 shows the collected ABNF with the list |  | 1.2 of [Part1]. Appendix C describes rules imported from other |
| rule expanded. |  | documents. Appendix D shows the collected ABNF with the list rule |
|  |  | expanded. |
| The following core rules are included by reference, as defined in |  |  |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), 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 8-bit |  |  |
| sequence of data), SP (space), and VCHAR (any visible US-ASCII |  |  |
| character). |  |  |
| Note that all rules derived from token are to be compared case- |  |  |
| insensitively, like range-unit and acceptable-ranges. |  |  |
| 1.2.1. Core Rules |  |  |
| The core rules below are defined in [Part1] and [Part2]: |  |  |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  |  |
| token = <token, defined in [Part1], Section 3.2.4> |  |  |
| HTTP-date = <HTTP-date, defined in [Part2], Section 8> |  |  |
| 1.2.2. ABNF Rules defined in other Parts of the Specification |  |  |
| The ABNF rules below are defined in other parts: |  |  |
| entity-tag = <entity-tag, defined in [Part4], Section 2.3> |  |  |
| 2. Range Units |  | 2. 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 |
| representation be included within the response. HTTP/1.1 uses range |  | representation 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 5.4) and Content-Range (Section 5.2) |
| header fields. A representation can be broken down into subranges |  | header fields. A representation can be broken down into subranges |
| according to various structural units. |  | according to various structural units. |
| range-unit = bytes-unit / other-range-unit |  | range-unit = bytes-unit / other-range-unit |
| skipping to change at page 7, line 7 |  | skipping to change at page 6, line 44 |
| o Either a Content-Range header field (Section 5.2) indicating the |  | o Either a Content-Range header field (Section 5.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 Cache-Control, ETag, Expires, Content-Location, Last-Modified, |  | o Cache-Control, ETag, Expires, Content-Location and/or Vary, if the |
| and/or Vary, if the header field would have been sent in a 200 |  | header field would have been sent in a 200 (OK) response to the |
| response to the same request |  | same request |
| If the 206 response is the result of an If-Range request, the |  | If a 206 is sent in response to a request with an If-Range header |
| response SHOULD NOT include other representation header fields. |  | field, it SHOULD NOT include other representation header fields. |
| Otherwise, the response MUST include all of the representation header |  | Otherwise, the response MUST include all of the representation header |
| fields that would have been returned with a 200 (OK) response to the |  | fields that would have been returned with a 200 (OK) response to the |
| same request. |  | same request. |
| Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to |  | Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |
| determine freshness for 206 responses. |  | determine freshness for 206 responses. |
| 3.2. 416 Requested Range Not Satisfiable |  | 3.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 header field (Section 5.4), and none of the ranges- |  | included a Range header field (Section 5.4), and none of the ranges- |
| specifier values in this field overlap the current extent of the |  | specifier values in this field overlap the current extent of the |
| selected resource, and the request did not include an If-Range header |  | selected resource, and the request did not include an If-Range header |
| field (Section 5.3). (For byte-ranges, this means that the first- |  | field (Section 5.3). (For byte-ranges, this means that the first- |
| byte-pos of all of the byte-range-spec values were greater than the |  | byte-pos of all of the byte-range-spec values were greater than the |
| skipping to change at page 7, line 42 |  | skipping to change at page 7, line 30 |
| current length of the representation (see Section 5.2). This |  | current length of the representation (see Section 5.2). This |
| response MUST NOT use the multipart/byteranges content-type. For |  | response MUST NOT use the multipart/byteranges content-type. For |
| example, |  | example, |
| HTTP/1.1 416 Requested Range Not Satisfiable |  | HTTP/1.1 416 Requested Range Not Satisfiable |
| Date: Mon, 20 Jan 2012 15:41:54 GMT |  | Date: Mon, 20 Jan 2012 15:41:54 GMT |
| Content-Range: bytes */47022 |  | Content-Range: bytes */47022 |
| Content-Type: image/gif |  | Content-Type: image/gif |
| 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 header field, since not all servers |  | an unsatisfiable Range header field, since not all servers |
| implement this header field. |  | implement this header field. |
| 4. Responses to a Range Request |  | 4. Responses to a Range Request |
| 4.1. Response to a Single and Multiple Ranges Request |  | 4.1. Response to a Single and Multiple Ranges Request |
| When an HTTP message includes the content of a single range (for |  | When an HTTP message includes the content of a single range (for |
| example, a response to a request for a single range, or to a request |  | example, a response to a request for a single range, or to a request |
| for a set of ranges that overlap without any holes), this content is |  | for a set of ranges that overlap without any holes), this content is |
| skipping to change at page 8, line 22 |  | skipping to change at page 8, line 10 |
| Content-Length: 26012 |  | Content-Length: 26012 |
| Content-Type: image/gif |  | Content-Type: image/gif |
| When an HTTP message includes the content of multiple ranges (for |  | When an HTTP message includes the content of multiple ranges (for |
| example, a response to a request for multiple non-overlapping |  | example, a response to a request for multiple non-overlapping |
| ranges), these are transmitted as a multipart message. The multipart |  | ranges), these are transmitted as a multipart message. The multipart |
| media type used for this purpose is "multipart/byteranges" as defined |  | media type used for this purpose is "multipart/byteranges" as defined |
| in Appendix A. |  | in Appendix A. |
| A server MAY combine requested ranges when those ranges are |  | A server MAY combine requested ranges when those ranges are |
| overlapping (see Section 7). |  | overlapping (see Section 7.1). |
| A response to a request for a single range MUST NOT be sent using the |  | A response to a request for a single range MUST NOT be sent using the |
| multipart/byteranges media type. A response to a request for |  | multipart/byteranges media type. A response to a request for |
| multiple ranges, whose result is a single range, MAY be sent as a |  | multiple ranges, whose result is a single range, MAY be sent as a |
| multipart/byteranges media type with one part. A client that cannot |  | multipart/byteranges media type with one part. A client that cannot |
| decode a multipart/byteranges message MUST NOT ask for multiple |  | decode a multipart/byteranges message MUST NOT ask for multiple |
| ranges in a single request. |  | ranges in a single request. |
| When a client requests multiple ranges in one request, the server |  | When a client asks for multiple ranges in one request, the server |
| SHOULD return them in the order that they appeared in the request. |  | SHOULD return them in the order that they appeared in the request. |
| 4.2. Combining Ranges |  | 4.2. Combining Ranges |
| A response might transfer only a subrange of a representation if the |  | A response might transfer only a subrange of a representation if the |
| connection closed prematurely or if the request used one or more |  | connection closed prematurely or if the request used one or more |
| Range specifications. After several such transfers, a client might |  | Range specifications. After several such transfers, a client might |
| have received several ranges of the same representation. These |  | have received several ranges of the same representation. These |
| ranges can only be safely combined if they all have in common the |  | ranges can only be safely combined if they all have in common the |
| same strong validator, where "strong validator" is defined to be |  | same strong validator, where "strong validator" is defined to be |
| skipping to change at page 11, line 6 |  | skipping to change at page 10, line 46 |
| 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. |
| In the case of a byte range request: A server sending a response with |  | In the case of a byte range request: A server sending a response with |
| status code 416 (Requested range not satisfiable) SHOULD include a |  | status code 416 (Requested Range Not Satisfiable) SHOULD include a |
| Content-Range field with a byte-range-resp-spec of "*". The |  | Content-Range field with a byte-range-resp-spec of "*". The |
| instance-length specifies the current length of the selected |  | instance-length specifies the current length of the selected |
| resource. A response with status code 206 (Partial Content) MUST NOT |  | resource. A response with status code 206 (Partial Content) MUST NOT |
| include a Content-Range field with a byte-range-resp-spec of "*". |  | include a Content-Range field with a byte-range-resp-spec of "*". |
| The "Content-Range" header field has no meaning for status codes that |  | The "Content-Range" header field has no meaning for status codes that |
| do not explicitly describe its semantic. Currently, only status |  | do not explicitly describe its semantic. Currently, only status |
| codes 206 (Partial Content) and 416 (Requested range not satisfiable) |  | codes 206 (Partial Content) and 416 (Requested Range Not Satisfiable) |
| describe the meaning of this header field. |  | describe the meaning of this header field. |
| Examples of byte-content-range-spec values, assuming that the |  | Examples of byte-content-range-spec values, assuming that the |
| representation contains a total of 1234 bytes: |  | representation contains a total of 1234 bytes: |
| o The first 500 bytes: |  | o The first 500 bytes: |
| bytes 0-499/1234 |  | bytes 0-499/1234 |
| o The second 500 bytes: |  | o The second 500 bytes: |
| skipping to change at page 11, line 37 |  | skipping to change at page 11, line 28 |
| o All except for the first 500 bytes: |  | o All except for the first 500 bytes: |
| bytes 500-1233/1234 |  | bytes 500-1233/1234 |
| o The last 500 bytes: |  | o The last 500 bytes: |
| bytes 734-1233/1234 |  | bytes 734-1233/1234 |
| If the server ignores a byte-range-spec (for example if it is |  | If the server ignores a byte-range-spec (for example if it is |
| syntactically invalid, or if it may be seen as a denial-of-service |  | syntactically invalid, or if it might be seen as a denial-of-service |
| attack), the server SHOULD treat the request as if the invalid Range |  | attack), 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 (OK) |
| response containing the full representation). |  | response containing the full representation). |
| 5.3. If-Range |  | 5.3. If-Range |
| If a client has a partial copy of a representation and wishes to have |  | If a client has a partial copy of a representation and wishes to have |
| an up-to-date copy of the entire representation, it could use the |  | an up-to-date copy of the entire representation, it could use the |
| Range header field with a conditional GET (using either or both of |  | Range header field with a conditional GET (using either or both of |
| If-Unmodified-Since and If-Match.) However, if the condition fails |  | If-Unmodified-Since and If-Match.) However, if the condition fails |
| because the representation has been modified, the client would then |  | because the representation has been modified, the client would then |
| have to make a second request to obtain the entire current |  | have to make a second request to obtain the entire current |
| skipping to change at page 13, line 46 |  | skipping to change at page 13, line 38 |
| (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 |
| (Requested range not satisfiable) status code. Otherwise, the server |  | (Requested Range Not Satisfiable) status code. Otherwise, the server |
| SHOULD return a response with a 206 (Partial Content) status code |  | SHOULD return a response with a 206 (Partial Content) status code |
| containing the satisfiable ranges of the representation. |  | containing the satisfiable ranges of the representation. |
|  |  | In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- |
|  |  | length are expressed as decimal number of octets. Since there is no |
|  |  | predefined limit to the length of an HTTP payload, recipients SHOULD |
|  |  | anticipate potentially large decimal numerals and prevent parsing |
|  |  | errors due to integer conversion overflows. |
| Examples of byte-ranges-specifier values (assuming a representation |  | Examples of byte-ranges-specifier values (assuming a representation |
| of length 10000): |  | of length 10000): |
| o The first 500 bytes (byte offsets 0-499, inclusive): |  | o The first 500 bytes (byte offsets 0-499, inclusive): |
| bytes=0-499 |  | bytes=0-499 |
| o The second 500 bytes (byte offsets 500-999, inclusive): |  | o The second 500 bytes (byte offsets 500-999, inclusive): |
| bytes=500-999 |  | bytes=500-999 |
| skipping to change at page 16, line 15 |  | skipping to change at page 16, line 15 |
| 6.3. Range Specifier Registration |  | 6.3. Range Specifier Registration |
| The registration procedure for HTTP Range Specifiers is defined by |  | The registration procedure for HTTP Range Specifiers is defined by |
| Section 2.1 of this document. |  | Section 2.1 of this document. |
| The HTTP Range Specifier Registry shall be created at |  | The HTTP Range Specifier Registry shall be created at |
| <http://www.iana.org/assignments/http-range-specifiers> and be |  | <http://www.iana.org/assignments/http-range-specifiers> and be |
| populated with the registrations below: |  | populated with the registrations below: |
| +----------------------+-------------------+----------------------+ |  | +---------------+-------------------------------------+-------------+ |
| | Range Specifier Name | Description | Reference | |  | | Range | Description | Reference | |
| +----------------------+-------------------+----------------------+ |  | | Specifier | | | |
| | bytes | a range of octets | (this specification) | |  | | Name | | | |
| +----------------------+-------------------+----------------------+ |  | +---------------+-------------------------------------+-------------+ |
|  |  | | bytes | a range of octets | Section 2 | |
|  |  | | none | reserved as keyword, indicating no | Section 5.1 | |
|  |  | | | ranges are supported | | |
|  |  | +---------------+-------------------------------------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 7. Security Considerations |  | 7. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 7.1. Overlapping Ranges |  | 7.1. Overlapping Ranges |
| Range requests containing overlapping ranges may lead to the |  | Range requests containing overlapping ranges can lead to the |
| situation where a server is sending far more data than the size of |  | situation where a server is sending far more data than the size of |
| 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., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 1: URIs, Connections, and Message |  | "HTTP/1.1, part 1: Message Routing and Syntax"", |
| Parsing", draft-ietf-httpbis-p1-messaging-19 (work in |  | draft-ietf-httpbis-p1-messaging-20 (work in progress), |
| progress), March 2012. |  | July 2012. |
| [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 2: Message Semantics", |  | "HTTP/1.1, part 2: Semantics and Payloads", |
| draft-ietf-httpbis-p2-semantics-19 (work in progress), |  | draft-ietf-httpbis-p2-semantics-20 (work in progress), |
| March 2012. |  | July 2012. |
| [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 4: Conditional Requests", |  | "HTTP/1.1, part 4: Conditional Requests", |
| draft-ietf-httpbis-p4-conditional-19 (work in progress), |  | draft-ietf-httpbis-p4-conditional-20 (work in progress), |
| March 2012. |  | July 2012. |
| [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |  | [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., 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-19 (work in progress), |  | draft-ietf-httpbis-p6-cache-20 (work in progress), |
| March 2012. |  | July 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 18, line 6 |  | skipping to change at page 18, line 14 |
| 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 ([RFC2046], Section 5.1). The media type for this purpose is |  | body ([RFC2046], Section 5.1). The media type for this purpose is |
| called "multipart/byteranges". The following is to be registered |  | called "multipart/byteranges". The following is to be registered |
| with IANA [RFC4288]. |  | with IANA [RFC4288]. |
| Note: Despite the name "multipart/byteranges" is not limited to |  |  |
| the byte ranges only. |  |  |
| The multipart/byteranges media type includes one or more parts, each |  | The multipart/byteranges media type includes one 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. |
| Type name: multipart |  | Type name: multipart |
| Subtype name: byteranges |  | Subtype name: byteranges |
| Required parameters: boundary |  | Required parameters: boundary |
| skipping to change at page 18, line 31 |  | skipping to change at page 18, line 36 |
| 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 |  | Interoperability considerations: none |
| Published specification: This specification (see Appendix A). |  | Published specification: This specification (see Appendix A). |
| Applications that use this media type: |  | Applications that use this media type: HTTP components supporting |
|  |  | multiple ranges in a single request. |
| Additional information: |  | Additional information: |
| Magic number(s): none |  | Magic number(s): none |
| File extension(s): none |  | File extension(s): none |
| 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/Change controller: IESG |
|  |  | Note: Despite the name "multipart/byteranges" is not limited to |
|  |  | the byte ranges only. |
| 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 |
| ...the first range... |  | ...the first range... |
| --THIS_STRING_SEPARATES |  | --THIS_STRING_SEPARATES |
| Content-type: application/pdf |  | Content-type: application/pdf |
| Content-range: bytes 7000-7999/8000 |  | Content-range: bytes 7000-7999/8000 |
| ...the second range |  | ...the second range |
| --THIS_STRING_SEPARATES-- |  | --THIS_STRING_SEPARATES-- |
| Other example: |  | Another example, using the "exampleunit" range unit: |
| HTTP/1.1 206 Partial Content |  | HTTP/1.1 206 Partial Content |
| Date: Tue, 14 Nov 1995 06:25:24 GMT |  | Date: Tue, 14 Nov 1995 06:25:24 GMT |
| Last-Modified: Tue, 14 July 04:58:08 GMT |  | Last-Modified: Tue, 14 July 04:58:08 GMT |
| Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |  | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
| --THIS_STRING_SEPARATES |  | --THIS_STRING_SEPARATES |
| Content-type: video/example |  | Content-type: video/example |
| Content-range: exampleunit 1.2-4.3/25 |  | Content-range: exampleunit 1.2-4.3/25 |
| skipping to change at page 20, line 5 |  | skipping to change at page 20, line 12 |
| Notes: |  | Notes: |
| 1. Additional CRLFs MAY precede the first boundary string in the |  | 1. Additional CRLFs MAY 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. |
| 3. A number of browsers and servers were coded to an early draft of |  | 3. A number of clients and servers were coded to an early draft of |
| the byteranges specification to use a media type of multipart/ |  | the byteranges specification to use a media type of multipart/ |
| 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) |
| 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 |  | Change ABNF productions for header fields to only define the field |
| value. (Section 5) |  | 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. Collected ABNF |  | Appendix C. Imported ABNF |
|  |  | The following core rules are included by reference, as defined in |
|  |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
|  |  | 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 |
|  |  | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
|  |  | character). |
|  |  | Note that all rules derived from token are to be compared case- |
|  |  | insensitively, like range-unit and acceptable-ranges. |
|  |  | The rules below are defined in [Part1]: |
|  |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
|  |  | token = <token, defined in [Part1], Section 3.2.4> |
|  |  | The rules below are defined in other parts: |
|  |  | HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> |
|  |  | entity-tag = <entity-tag, defined in [Part4], Section 2.3> |
|  |  | 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 8> |  | HTTP-date = <HTTP-date, defined in [Part2], Section 5.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" |
| byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( |  | byte-content-range-spec = bytes-unit SP 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 ) / "*" |
| byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( |  | byte-range-set = *( "," OWS ) ( byte-range-spec / |
| suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / |  | suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / |
| suffix-byte-range-spec ] ) ) |  | suffix-byte-range-spec ) ] ) |
| byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |  | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] |
| byte-ranges-specifier = bytes-unit "=" byte-range-set |  | byte-ranges-specifier = bytes-unit "=" byte-range-set |
| bytes-unit = "bytes" |  | bytes-unit = "bytes" |
| entity-tag = <entity-tag, defined in [Part4], Section 2.3> |  | entity-tag = <entity-tag, defined in [Part4], Section 2.3> |
| first-byte-pos = 1*DIGIT |  | first-byte-pos = 1*DIGIT |
| instance-length = 1*DIGIT |  | instance-length = 1*DIGIT |
| skipping to change at page 22, line 4 |  | skipping to change at page 22, line 4 |
| other-range-set = 1*CHAR |  | other-range-set = 1*CHAR |
| other-range-unit = token |  | other-range-unit = token |
| other-ranges-specifier = other-range-unit "=" other-range-set |  | other-ranges-specifier = other-range-unit "=" other-range-set |
| range-unit = bytes-unit / other-range-unit |  | range-unit = bytes-unit / other-range-unit |
| suffix-byte-range-spec = "-" suffix-length |  | suffix-byte-range-spec = "-" suffix-length |
| suffix-length = 1*DIGIT |  | suffix-length = 1*DIGIT |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.4> |
| ABNF diagnostics: |  |  |
| ; Accept-Ranges defined but not used |  |  |
| ; Content-Range defined but not used |  |  |
| ; If-Range defined but not used |  |  |
| ; Range defined but not used |  |  |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  |  |
| D.1. Since RFC 2616 |  |  |
| Extracted relevant partitions from [RFC2616]. |  |  |
| D.2. Since draft-ietf-httpbis-p5-range-00 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache |  |  |
| validators in 206 responses" |  |  |
| (<http://purl.org/NET/http-errata#ifrange206>) |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  |  |
| Informative references" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |  |  |
| to-date references" |  |  |
| D.3. Since draft-ietf-httpbis-p5-range-01 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |  |  |
| RFC4288" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Add explicit references to BNF syntax and rules imported from |  |  |
| other parts of the specification. |  |  |
| D.4. Since draft-ietf-httpbis-p5-range-02 |  |  |
| Ongoing work on IANA Message Header Field Registration |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  |  |
| o Reference RFC 3984, and update header field registrations for |  |  |
| headers defined in this document. |  |  |
| D.5. Since draft-ietf-httpbis-p5-range-03 |  |  |
| None. |  |  |
| D.6. Since draft-ietf-httpbis-p5-range-04 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/ |  |  |
| byteranges minimum number of parts" |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Use "/" instead of "|" for alternatives. |  |  |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  |  |
| whitespace ("OWS") and required whitespace ("RWS"). |  |  |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  |  |
| field value format definitions. |  |  |
| D.7. Since draft-ietf-httpbis-p5-range-05 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base |  |  |
| for *-byte-pos and suffix-length" |  |  |
| Ongoing work on Custom Ranges |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>): |  |  |
| o Remove bias in favor of byte ranges; allow custom ranges in ABNF. |  |  |
| Final work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Add appendix containing collected and expanded ABNF, reorganize |  |  |
| ABNF introduction. |  |  |
| D.8. Since draft-ietf-httpbis-p5-range-06 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  |  |
| numeric protocol elements" |  |  |
| D.9. Since draft-ietf-httpbis-p5-range-07 |  |  |
| Closed issues: |  |  |
| o Fixed discrepancy in the If-Range definition about allowed |  |  |
| validators. |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/150>: "multipart/ |  | Appendix E. Change Log (to be removed by RFC Editor before publication) |
| byteranges for custom range units" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/151>: "range unit |  |  |
| missing from other-ranges-specifier in Range header" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |  |  |
| registrations for optional status codes" |  |  |
| D.10. Since draft-ietf-httpbis-p5-range-08 |  |  |
| No significant changes. |  |  |
| D.11. Since draft-ietf-httpbis-p5-range-09 |  |  |
| No significant changes. |  |  |
| D.12. Since draft-ietf-httpbis-p5-range-10 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |  |  |
| 'Requested Variant'" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |  |  |
| entity / representation / variant terminology" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  |  |
| removing the 'changes from 2068' sections" |  |  |
| Ongoing work on Custom Ranges |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>): |  |  |
| o Add IANA registry. |  |  |
| D.13. Since draft-ietf-httpbis-p5-range-11 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't |  |  |
| be required to serve ranges" |  |  |
| D.14. Since draft-ietf-httpbis-p5-range-12 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header |  |  |
| Classification" |  |  |
| D.15. Since draft-ietf-httpbis-p5-range-13 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| D.16. Since draft-ietf-httpbis-p5-range-14 |  |  |
| None. |  |  |
| D.17. Since draft-ietf-httpbis-p5-range-15 |  |  |
| Closed issues: |  |  |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security |  | Changes up to the first Working Group Last Call draft are summarized |
| consideration: range flooding" |  | in <http://tools.ietf.org/html/ |
|  |  | draft-ietf-httpbis-p5-range-19#appendix-D>. |
| D.18. Since draft-ietf-httpbis-p5-range-16 |  | E.1. Since draft-ietf-httpbis-p5-range-19 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/358>: "ABNF list |
| HTTP's error-handling philosophy" |  | expansion code problem" |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content- |  |  |
| Range on responses other than 206" |  |  |
| o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case |  |  |
| sensitivity of ranges in p5" |  |  |
| D.19. Since draft-ietf-httpbis-p5-range-17 |  |  |
| None. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |
|  |  | requirements for recipients" |
| D.20. Since draft-ietf-httpbis-p5-range-18 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve |
|  |  | 'none' as byte range unit" |
| Closed issues: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |
|  |  | introduction of new IANA registries as normative changes" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units |
| limitations to Range to reduce its use as a denial-of-service |  | vs leading zeroes vs size" |
| tool" |  |  |
| Index |  | Index |
| 2 |  | 2 |
| 206 Partial Content (status code) 6 |  | 206 Partial Content (status code) 6 |
| 4 |  | 4 |
| 416 Requested Range Not Satisfiable (status code) 7 |  | 416 Requested Range Not Satisfiable (status code) 7 |
| A |  | A |
| skipping to change at page 26, line 26 |  | skipping to change at page 22, line 50 |
| C |  | C |
| Content-Range header field 10 |  | Content-Range header field 10 |
| G |  | G |
| Grammar |  | Grammar |
| Accept-Ranges 9 |  | Accept-Ranges 9 |
| acceptable-ranges 9 |  | acceptable-ranges 9 |
| byte-content-range-spec 10 |  | byte-content-range-spec 10 |
| byte-range-resp-spec 10 |  | byte-range-resp-spec 10 |
| byte-range-set 13 |  | byte-range-set 12 |
| byte-range-spec 13 |  | byte-range-spec 12 |
| byte-ranges-specifier 13 |  | byte-ranges-specifier 12 |
| bytes-unit 5 |  | bytes-unit 5 |
| Content-Range 10 |  | Content-Range 10 |
| first-byte-pos 13 |  | first-byte-pos 12 |
| If-Range 12 |  | If-Range 11 |
| instance-length 10 |  | instance-length 10 |
| last-byte-pos 13 |  | last-byte-pos 12 |
| other-range-unit 5 |  | other-range-unit 5 |
| Range 14 |  | Range 14 |
| range-unit 5 |  | range-unit 5 |
| ranges-specifier 13 |  | ranges-specifier 12 |
| suffix-byte-range-spec 13 |  | suffix-byte-range-spec 13 |
| suffix-length 13 |  | suffix-length 13 |
| H |  | H |
| Header Fields |  | Header Fields |
| Accept-Ranges 9 |  | Accept-Ranges 9 |
| Content-Range 10 |  | Content-Range 10 |
| If-Range 11 |  | If-Range 11 |
| Range 12 |  | Range 12 |
| I |  | I |
| If-Range header field 11 |  | If-Range header field 11 |
| M |  | M |
| Media Type |  | Media Type |
| multipart/byteranges 17 |  | multipart/byteranges 18 |
| multipart/x-byteranges 20 |  | multipart/x-byteranges 20 |
| multipart/byteranges Media Type 17 |  | multipart/byteranges Media Type 18 |
| multipart/x-byteranges Media Type 20 |  | multipart/x-byteranges Media Type 20 |
| R |  | R |
| Range header field 12 |  | Range header field 12 |
| S |  | S |
| Status Codes |  | Status Codes |
| 206 Partial Content 6 |  | 206 Partial Content 6 |
| 416 Requested Range Not Satisfiable 7 |  | 416 Requested Range Not Satisfiable 7 |
| skipping to change at page 28, line 4 |  | skipping to change at page 24, line 25 |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| EMail: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  |  |
| Fax: +49 251 2807761 |  |  |
| EMail: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 61 change blocks.
| 321 lines changed or deleted |  | 150 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/