| p5-range.unpg.txt |  | rfc7233.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
| Internet-Draft Adobe |  | Request for Comments: 7233 Adobe |
| Obsoletes: 2616 (if approved) Y. Lafon, Ed. |  | Obsoletes: 2616 Y. Lafon, Ed. |
| Intended status: Standards Track W3C |  | Category: Standards Track W3C |
| Expires: December 8, 2014 J. Reschke, Ed. |  | ISSN: 2070-1721 J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| June 6, 2014 |  | June 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Range Requests |  | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| draft-ietf-httpbis-p5-range-latest |  |  |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is a stateless application- |  | The Hypertext Transfer Protocol (HTTP) is a stateless application- |
| level protocol for distributed, collaborative, hypertext information |  | level 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) |  |  |
| Discussion of this draft takes place on the HTTPBIS working group |  |  |
| mailing list (ietf-http-wg@w3.org), which is archived at |  |  |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  |  |
| The current issues list is at |  |  |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  |  |
| documents (including fancy diffs) can be found at |  |  |
| <http://tools.ietf.org/wg/httpbis/>. |  |  |
| _This is a temporary document for the purpose of tracking the |  |  |
| editorial changes made during the AUTH48 (RFC publication) phase._ |  |  |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This is an Internet Standards Track document. |
| provisions of BCP 78 and BCP 79. |  |  |
| Internet-Drafts are working documents of the Internet Engineering |  | This document is a product of the Internet Engineering Task Force |
| Task Force (IETF). Note that other groups may also distribute |  | (IETF). It represents the consensus of the IETF community. It has |
| working documents as Internet-Drafts. The list of current Internet- |  | received public review and has been approved for publication by the |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Internet Engineering Steering Group (IESG). Further information on |
|  |  | Internet Standards is available in Section 2 of RFC 5741. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Information about the current status of this document, any errata, |
| and may be updated, replaced, or obsoleted by other documents at any |  | and how to provide feedback on it may be obtained at |
| time. It is inappropriate to use Internet-Drafts as reference |  | http://www.rfc-editor.org/info/rfc7233. |
| material or to cite them other than as "work in progress." |  |  |
| This Internet-Draft will expire on December 8, 2014. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2014 IETF Trust and the persons identified as the |  | Copyright (c) 2014 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 7 |  | skipping to change at page 3, line 7 |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| 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 . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation ............................................4 |
| 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 2. Range Units .....................................................5 |
| 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Byte Ranges ................................................5 |
| 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 |  | 2.2. Other Range Units ..........................................7 |
| 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.3. Accept-Ranges ..............................................7 |
| 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3. Range Requests ..................................................8 |
| 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 3.1. Range ......................................................8 |
| 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 3.2. If-Range ...................................................9 |
| 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10 |  | 4. Responses to a Range Request ...................................10 |
| 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 |  | 4.1. 206 Partial Content .......................................10 |
| 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 |  | 4.2. Content-Range .............................................12 |
| 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 |  | 4.3. Combining Ranges ..........................................14 |
| 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 |  | 4.4. 416 Range Not Satisfiable .................................15 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 |  | 5. IANA Considerations ............................................16 |
| 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 |  | 5.1. Range Unit Registry .......................................16 |
| 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 |  | 5.1.1. Procedure ..........................................16 |
| 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 |  | 5.1.2. Registrations ......................................16 |
| 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 |  | 5.2. Status Code Registration ..................................17 |
| 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 |  | 5.3. Header Field Registration .................................17 |
| 5.4. Internet Media Type Registration . . . . . . . . . . . . . 17 |  | 5.4. Internet Media Type Registration ..........................17 |
| 5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17 |  | 5.4.1. Internet Media Type multipart/byteranges ...........18 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 |  | 6. Security Considerations ........................................19 |
| 6.1. Denial-of-Service Attacks Using Range . . . . . . . . . . 18 |  | 6.1. Denial-of-Service Attacks Using Range .....................19 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 7. Acknowledgments ................................................19 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 8. References .....................................................20 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 |  | 8.1. Normative References ......................................20 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 |  | 8.2. Informative References ....................................20 |
| Appendix A. Internet Media Type multipart/byteranges . . . . . . 20 |  | Appendix A. Internet Media Type multipart/byteranges ..............21 |
| Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 |  | Appendix B. Changes from RFC 2616 .................................22 |
| Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 |  | Appendix C. Imported ABNF .........................................22 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 |  | Appendix D. Collected ABNF ........................................23 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 |  | Index .............................................................24 |
| 1. Introduction |  | 1. Introduction |
| Hypertext Transfer Protocol (HTTP) clients often encounter |  | Hypertext Transfer Protocol (HTTP) clients often encounter |
| interrupted data transfers as a result of canceled requests or |  | interrupted data transfers as a result of canceled requests or |
| dropped connections. When a client has stored a partial |  | dropped connections. When a client has stored a partial |
| representation, it is desirable to request the remainder of that |  | representation, it is desirable to request the remainder of that |
| representation in a subsequent request rather than transfer the |  | representation in a subsequent request rather than transfer the |
| entire representation. Likewise, devices with limited local storage |  | entire representation. Likewise, devices with limited local storage |
| might benefit from being able to request only a subset of a larger |  | might benefit from being able to request only a subset of a larger |
| skipping to change at page 6, line 16 |  | skipping to change at page 6, line 22 |
| the remainder of the representation (i.e., the server replaces the |  | the remainder of the representation (i.e., the server replaces the |
| value of last-byte-pos with a value that is one less than the current |  | value of last-byte-pos with a value that is one less than the current |
| length of the selected representation). |  | length of the selected representation). |
| A client can request the last N bytes of the selected representation |  | A client can request the last N bytes of the selected representation |
| using a suffix-byte-range-spec. |  | using a suffix-byte-range-spec. |
| suffix-byte-range-spec = "-" suffix-length |  | suffix-byte-range-spec = "-" suffix-length |
| suffix-length = 1*DIGIT |  | suffix-length = 1*DIGIT |
| If the selected representation is shorter than the specified suffix- |  | If the selected representation is shorter than the specified |
| length, the entire representation is used. |  | suffix-length, the entire representation is used. |
| Additional examples, assuming a representation of length 10000: |  | Additional examples, assuming a representation of length 10000: |
| o The final 500 bytes (byte offsets 9500-9999, inclusive): |  | o The final 500 bytes (byte offsets 9500-9999, inclusive): |
| bytes=-500 |  | bytes=-500 |
| Or: |  | Or: |
| bytes=9500- |  | bytes=9500- |
| o The first and last bytes only (bytes 0 and 9999): |  | o The first and last bytes only (bytes 0 and 9999): |
| bytes=0-0,-1 |  | bytes=0-0,-1 |
| o Other valid (but not canonical) specifications of the second 500 |  | o Other valid (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 |
| If a valid byte-range-set includes at least one byte-range-spec with |  | If a valid byte-range-set includes at least one byte-range-spec with |
| a first-byte-pos that is less than the current length of the |  | a first-byte-pos that is less than the current length of the |
| representation, or at least one suffix-byte-range-spec with a non- |  | representation, or at least one suffix-byte-range-spec with a |
| 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. |  | Otherwise, the byte-range-set is unsatisfiable. |
| In the byte-range syntax, first-byte-pos, last-byte-pos, and suffix- |  | In the byte-range syntax, first-byte-pos, last-byte-pos, and |
| length are expressed as decimal number of octets. Since there is no |  | suffix-length are expressed as decimal number of octets. Since there |
| predefined limit to the length of a payload, recipients MUST |  | is no predefined limit to the length of a payload, recipients MUST |
| anticipate potentially large decimal numerals and prevent parsing |  | anticipate potentially large decimal numerals and prevent parsing |
| errors due to integer conversion overflows. |  | errors due to integer conversion overflows. |
| 2.2. Other Range Units |  | 2.2. Other Range Units |
| Range units are intended to be extensible. New range units ought to |  | Range units are intended to be extensible. New range units ought to |
| be registered with IANA, as defined in Section 5.1. |  | be registered with IANA, as defined in Section 5.1. |
| other-range-unit = token |  | other-range-unit = token |
| skipping to change at page 9, line 23 |  | skipping to change at page 9, line 38 |
| representation. |  | representation. |
| The "If-Range" header field allows a client to "short-circuit" the |  | The "If-Range" header field allows a client to "short-circuit" the |
| second request. Informally, its meaning is as follows: if the |  | second request. Informally, its meaning is as follows: if the |
| representation is unchanged, send me the part(s) that I am requesting |  | representation is unchanged, send me the part(s) that I am requesting |
| in Range; otherwise, send me the entire representation. |  | in Range; otherwise, send me the entire representation. |
| If-Range = entity-tag / HTTP-date |  | If-Range = entity-tag / HTTP-date |
| A client MUST NOT generate an If-Range header field in a request that |  | A client MUST NOT generate an If-Range header field in a request that |
| does not contain a Range header field. A server MUST ignore an If- |  | does not contain a Range header field. A server MUST ignore an |
| Range header field received in a request that does not contain a |  | If-Range header field received in a request that does not contain a |
| Range header field. An origin server MUST ignore an If-Range header |  | Range header field. An origin server MUST ignore an If-Range header |
| field received in a request for a target resource that does not |  | field received in a request for a target resource that does not |
| support Range requests. |  | support Range requests. |
| A client MUST NOT generate an If-Range header field containing an |  | A client MUST NOT generate an If-Range header field containing an |
| entity-tag that is marked as weak. A client MUST NOT generate an If- |  | entity-tag that is marked as weak. A client MUST NOT generate an |
| Range header field containing an HTTP-date unless the client has no |  | If-Range header field containing an HTTP-date unless the client has |
| entity-tag for the corresponding representation and the date is a |  | no entity-tag for the corresponding representation and the date is a |
| strong validator in the sense defined by Section 2.2.2 of [RFC7232]. |  | strong validator in the sense defined by Section 2.2.2 of [RFC7232]. |
| A server that evaluates an If-Range precondition MUST use the strong |  | A server that evaluates an If-Range precondition MUST use the strong |
| comparison function when comparing entity-tags (Section 2.3.2 of |  | comparison function when comparing entity-tags (Section 2.3.2 of |
| [RFC7232]) and MUST evaluate the condition as false if an HTTP-date |  | [RFC7232]) and MUST evaluate the condition as false if an HTTP-date |
| validator is provided that is not a strong validator in the sense |  | validator is provided that is not a strong validator in the sense |
| defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be |  | defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be |
| distinguished from a valid HTTP-date by examining the first two |  | distinguished from a valid HTTP-date by examining the first two |
| characters for a DQUOTE. |  | characters for a DQUOTE. |
| If the validator given in the If-Range header field matches the |  | If the validator given in the If-Range header field matches the |
| current validator for the selected representation of the target |  | current validator for the selected representation of the target |
| resource, then the server SHOULD process the Range header field as |  | resource, then the server SHOULD process the Range header field as |
| requested. If the validator does not match, the server MUST ignore |  | requested. If the validator does not match, the server MUST ignore |
| the Range header field. Note that this comparison by exact match, |  | the Range header field. Note that this comparison by exact match, |
| including when the validator is an HTTP-date, differs from the |  | including when the validator is an HTTP-date, differs from the |
| "earlier than or equal to" comparison used when evaluating an If- |  | "earlier than or equal to" comparison used when evaluating an |
| Unmodified-Since conditional. |  | If-Unmodified-Since conditional. |
| 4. Responses to a Range Request |  | 4. Responses to a Range Request |
| 4.1. 206 Partial Content |  | 4.1. 206 Partial Content |
| The 206 (Partial Content) status code indicates that the server is |  | The 206 (Partial Content) status code indicates that the server is |
| successfully fulfilling a range request for the target resource by |  | successfully fulfilling a range request for the target resource by |
| transferring one or more parts of the selected representation that |  | transferring one or more parts of the selected representation that |
| correspond to the satisfiable ranges found in the request's Range |  | correspond to the satisfiable ranges found in the request's Range |
| header field (Section 3.1). |  | header field (Section 3.1). |
| skipping to change at page 11, line 44 |  | skipping to change at page 11, line 51 |
| A server MUST NOT generate a multipart response to a request for a |  | A server MUST NOT generate a multipart response to a request for a |
| single range, since a client that does not request multiple parts |  | single range, since a client that does not request multiple parts |
| might not support multipart responses. However, a server MAY |  | might not support multipart responses. However, a server MAY |
| generate a multipart/byteranges payload with only a single body part |  | generate a multipart/byteranges payload with only a single body part |
| if multiple ranges were requested and only one range was found to be |  | if multiple ranges were requested and only one range was found to be |
| satisfiable or only one range remained after coalescing. A client |  | satisfiable or only one range remained after coalescing. A client |
| that cannot process a multipart/byteranges response MUST NOT generate |  | that cannot process a multipart/byteranges response MUST NOT generate |
| a request that asks for multiple ranges. |  | a request that asks for multiple ranges. |
| When a multipart response payload is generated, the server SHOULD |  | When a multipart response payload is generated, the server SHOULD |
| send the parts in the same order that the corresponding byte-range- |  | send the parts in the same order that the corresponding |
| spec appeared in the received Range header field, excluding those |  | byte-range-spec appeared in the received Range header field, |
| ranges that were deemed unsatisfiable or that were coalesced into |  | excluding those ranges that were deemed unsatisfiable or that were |
| other ranges. A client that receives a multipart response MUST |  | coalesced into other ranges. A client that receives a multipart |
| inspect the Content-Range header field present in each body part in |  | response MUST inspect the Content-Range header field present in each |
| order to determine which range is contained in that body part; a |  | body part in order to determine which range is contained in that body |
| client cannot rely on receiving the same ranges that it requested, |  | part; a client cannot rely on receiving the same ranges that it |
| nor the same order that it requested. |  | requested, nor the same order that it requested. |
| When a 206 response is generated, the server MUST generate the |  | When a 206 response is generated, the server MUST generate the |
| following header fields, in addition to those required above, if the |  | following header fields, in addition to those required above, if the |
| field would have been sent in a 200 (OK) response to the same |  | field would have been sent in a 200 (OK) response to the same |
| request: Date, Cache-Control, ETag, Expires, Content-Location, and |  | request: Date, Cache-Control, ETag, Expires, Content-Location, and |
| Vary. |  | Vary. |
| If a 206 is generated in response to a request with an If-Range |  | If a 206 is generated in response to a request with an If-Range |
| header field, the sender SHOULD NOT generate other representation |  | header field, the sender SHOULD NOT generate other representation |
| header fields beyond those required above, because the client is |  | header fields beyond those required above, because the client is |
| skipping to change at page 13, line 22 |  | skipping to change at page 13, line 28 |
| The following example illustrates when the complete length of the |  | The following example illustrates when the complete length of the |
| selected representation is known by the sender to be 1234 bytes: |  | selected representation is known by the sender to be 1234 bytes: |
| Content-Range: bytes 42-1233/1234 |  | Content-Range: bytes 42-1233/1234 |
| and this second example illustrates when the complete length is |  | and this second example illustrates when the complete length is |
| unknown: |  | unknown: |
| Content-Range: bytes 42-1233/* |  | Content-Range: bytes 42-1233/* |
| A Content-Range field value is invalid if it contains a byte-range- |  | A Content-Range field value is invalid if it contains a |
| resp that has a last-byte-pos value less than its first-byte-pos |  | byte-range-resp that has a last-byte-pos value less than its |
| value, or a complete-length value less than or equal to its last- |  | first-byte-pos value, or a complete-length value less than or equal |
| byte-pos value. The recipient of an invalid Content-Range MUST NOT |  | to its last-byte-pos value. The recipient of an invalid |
| attempt to recombine the received content with a stored |  | Content-Range MUST NOT attempt to recombine the received content with |
| representation. |  | a stored representation. |
| A server generating a 416 (Range Not Satisfiable) response to a byte- |  | A server generating a 416 (Range Not Satisfiable) response to a |
| range request SHOULD send a Content-Range header field with an |  | byte-range request SHOULD send a Content-Range header field with an |
| unsatisfied-range value, as in the following example: |  | unsatisfied-range value, as in the following example: |
| Content-Range: bytes */1234 |  | Content-Range: bytes */1234 |
| The complete-length in a 416 response indicates the current length of |  | The complete-length in a 416 response indicates the current length of |
| the selected representation. |  | the selected representation. |
| 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. For this specification, |  | do not explicitly describe its semantic. For this specification, |
| only the 206 (Partial Content) and 416 (Range Not Satisfiable) status |  | only the 206 (Partial Content) and 416 (Range Not Satisfiable) status |
| skipping to change at page 19, line 18 |  | skipping to change at page 20, line 21 |
| 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. |
| [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Message Syntax and Routing", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-latest (work in progress), |  | RFC 7230, June 2014. |
| June 2014. |  |  |
| [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Semantics and Content", |  | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, |
| draft-ietf-httpbis-p2-semantics-latest (work in progress), |  |  |
| June 2014. |  | June 2014. |
| [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Conditional Requests", |  | Protocol (HTTP/1.1): Conditional Requests", RFC 7232, |
| draft-ietf-httpbis-p4-conditional-latest (work in |  | June 2014. |
| progress), June 2014. |  |  |
| [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-latest (work in progress), |  | RFC 7234, June 2014. |
| June 2014. |  |  |
| 8.2. Informative References |  | 8.2. Informative References |
| [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |  | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type |
| Specifications and Registration Procedures", BCP 13, |  | Specifications and Registration Procedures", BCP 13, |
| RFC 6838, January 2013. |  | RFC 6838, January 2013. |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| skipping to change at page 21, line 30 |  | skipping to change at page 22, line 29 |
| Appendix C. Imported ABNF |  | Appendix C. Imported ABNF |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
| CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |  | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
| quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any |  | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any |
| 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |  | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| character). |  | character). |
| Note that all rules derived from token are to be compared case- |  | Note that all rules derived from token are to be compared |
| insensitively, like range-unit and acceptable-ranges. |  | case-insensitively, like range-unit and acceptable-ranges. |
| The rules below are defined in [RFC7230]: |  | The rules below are defined in [RFC7230]: |
| OWS = <OWS, see [RFC7230], Section 3.2.3> |  | OWS = <OWS, see [RFC7230], Section 3.2.3> |
| token = <token, see [RFC7230], Section 3.2.6> |  | token = <token, see [RFC7230], Section 3.2.6> |
| The rules below are defined in other parts: |  | The rules below are defined in other parts: |
| HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> |  | HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> |
| entity-tag = <entity-tag, see [RFC7232], Section 2.3> |  | entity-tag = <entity-tag, see [RFC7232], Section 2.3> |
| skipping to change at page 23, line 38 |  | skipping to change at page 24, line 43 |
| byte-ranges-specifier 5 |  | byte-ranges-specifier 5 |
| bytes-unit 5 |  | bytes-unit 5 |
| complete-length 12 |  | complete-length 12 |
| Content-Range 12 |  | Content-Range 12 |
| first-byte-pos 5 |  | first-byte-pos 5 |
| If-Range 9 |  | If-Range 9 |
| last-byte-pos 5 |  | last-byte-pos 5 |
| other-content-range 12 |  | other-content-range 12 |
| other-range-resp 12 |  | other-range-resp 12 |
| other-range-unit 5, 7 |  | other-range-unit 5, 7 |
| Range 7 |  | Range 8 |
| range-unit 5 |  | range-unit 5 |
| ranges-specifier 5 |  | ranges-specifier 5 |
| suffix-byte-range-spec 6 |  | suffix-byte-range-spec 6 |
| suffix-length 6 |  | suffix-length 6 |
| unsatisfied-range 12 |  | unsatisfied-range 12 |
| I |  | I |
| If-Range header field 9 |  | If-Range header field 9 |
| M |  | M |
| Media Type |  | Media Type |
| multipart/byteranges 17, 20 |  | multipart/byteranges 18, 21 |
| multipart/x-byteranges 20 |  | multipart/x-byteranges 19 |
| multipart/byteranges Media Type 17, 20 |  | multipart/byteranges Media Type 18, 21 |
| multipart/x-byteranges Media Type 20 |  | multipart/x-byteranges Media Type 21 |
| R |  | R |
| Range header field 7 |  | Range header field 8 |
| 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. 26 change blocks.
| 114 lines changed or deleted |  | 93 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/