draft-ietf-httpbis-p5-range-05.txt | draft-ietf-httpbis-p5-range-06.txt | |||
---|---|---|---|---|
Network Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Day Software | Internet-Draft Day Software | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Intended status: Standards Track One Laptop per Child | Intended status: Standards Track One Laptop per Child | |||
Expires: May 20, 2009 J. Mogul | Expires: September 10, 2009 J. Mogul | |||
HP | HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe Systems | Adobe Systems | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
November 16, 2008 | March 9, 2009 | |||
HTTP/1.1, part 5: Range Requests and Partial Responses | HTTP/1.1, part 5: Range Requests and Partial Responses | |||
draft-ietf-httpbis-p5-range-05 | draft-ietf-httpbis-p5-range-06 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. This document may contain material | |||
have been or will be disclosed, and any of which he or she becomes | from IETF Documents or IETF Contributions published or made publicly | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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." | |||
skipping to change at page 1, line 42 | skipping to change at page 2, line 4 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on May 20, 2009. | This Internet-Draft will expire on September 10, 2009. | |||
Copyright Notice | ||||
Copyright (c) 2009 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents in effect on the date of | ||||
publication of this document (http://trustee.ietf.org/license-info). | ||||
Please review these documents carefully, as they describe your rights | ||||
and restrictions with respect to this document. | ||||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 5 of the | information initiative since 1990. This document is Part 5 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines | |||
range-specific requests and the rules for constructing and combining | range-specific requests and the rules for constructing and combining | |||
responses to those requests. | 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 should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org). The current issues list is | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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 C.6. | The changes in this draft are summarized in Appendix D.7. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 | 1.2.2. ABNF Rules defined in other Parts of the | |||
4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 | Specification . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 | |||
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 | |||
6.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 | |||
6.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
6.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 | |||
6.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 | |||
6.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 | 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 | |||
6.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12 | 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
7.1. Message Header Registration . . . . . . . . . . . . . . . 13 | 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 6.1. Message Header Registration . . . . . . . . . . . . . . . 14 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | ||||
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 | ||||
Appendix A. Internet Media Type multipart/byteranges . . . . . . 15 | Appendix A. Internet Media Type multipart/byteranges . . . . . . 15 | |||
Appendix B. Compatibility with Previous Versions . . . . . . . . 17 | Appendix B. Compatibility with Previous Versions . . . . . . . . 17 | |||
B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17 | B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17 | |||
B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17 | B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 | |||
Appendix C. Change Log (to be removed by RFC Editor before | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 18 | |||
publication) . . . . . . . . . . . . . . . . . . . . 17 | Appendix D. Change Log (to be removed by RFC Editor before | |||
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17 | publication) . . . . . . . . . . . . . . . . . . . . 19 | |||
C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 18 | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 | |||
C.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 18 | D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20 | |||
C.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 18 | D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 20 | |||
C.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 18 | D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 20 | |||
C.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 18 | D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 20 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 20 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 | D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 23 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
1. Introduction | 1. Introduction | |||
HTTP clients often encounter interrupted data transfers as a result | HTTP clients often encounter interrupted data transfers as a result | |||
of cancelled requests or dropped connections. When a cache has | of cancelled requests or dropped connections. When a cache has | |||
stored a partial representation, it is desirable to request the | stored a partial representation, it is desirable to request the | |||
remainder of that representation in a subsequent request rather than | remainder of that representation in a subsequent request rather than | |||
transfer the entire representation. There are also a number of Web | transfer the entire representation. There are also a number of Web | |||
applications that benefit from being able to request only a subset of | applications that benefit from being able to request only a subset of | |||
a larger representation, such as a single page of a very large | a larger representation, such as a single page of a very large | |||
skipping to change at page 4, line 45 | skipping to change at page 4, line 45 | |||
An implementation is not compliant if it fails to satisfy one or more | An implementation is not compliant if it fails to satisfy one or more | |||
of the MUST or REQUIRED level requirements for the protocols it | of the MUST or REQUIRED level requirements for the protocols it | |||
implements. An implementation that satisfies all the MUST or | implements. An implementation that satisfies all the MUST or | |||
REQUIRED level and all the SHOULD level requirements for its | REQUIRED level and all the SHOULD level requirements for its | |||
protocols is said to be "unconditionally compliant"; one that | protocols is said to be "unconditionally compliant"; one that | |||
satisfies all the MUST level requirements but not all the SHOULD | satisfies all the MUST level requirements but not all the SHOULD | |||
level requirements for its protocols is said to be "conditionally | level requirements for its protocols is said to be "conditionally | |||
compliant." | compliant." | |||
2. Notational Conventions and Generic Grammar | 1.2. Syntax Notation | |||
This specification uses the ABNF syntax defined in Section 2.1 of | This specification uses the ABNF syntax defined in Section 1.2 of | |||
[Part1] and the core rules defined in Section 2.2 of [Part1]: | [Part1] (which extends the syntax defined in [RFC5234] with a list | |||
rule). Appendix C shows the collected ABNF, with the list rule | ||||
expanded. | ||||
DIGIT = <DIGIT, defined in [Part1], Section 2.2> | The following core rules are included by reference, as defined in | |||
SP = <SP, defined in [Part1], Section 2.2> | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
token = <token, defined in [Part1], Section 2.2> | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
OWS = <OWS, defined in [Part1], Section 2.2> | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | |||
sequence of data), SP (space), VCHAR (any visible USASCII character), | ||||
and WSP (whitespace). | ||||
1.2.1. Core Rules | ||||
The core rules below are defined in Section 1.2.2 of [Part1]: | ||||
token = <token, defined in [Part1], Section 1.2.2> | ||||
OWS = <OWS, defined in [Part1], Section 1.2.2> | ||||
1.2.2. ABNF Rules defined in other Parts of the Specification | ||||
The ABNF rules below are defined in other parts: | The ABNF rules below are defined in other parts: | |||
HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> | HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> | |||
entity-tag = <entity-tag, defined in [Part4], Section 3> | entity-tag = <entity-tag, defined in [Part4], Section 2> | |||
3. 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 | |||
response entity be included within the response. HTTP/1.1 uses range | response entity be included within the response. HTTP/1.1 uses range | |||
units in the Range (Section 6.4) and Content-Range (Section 6.2) | units in the Range (Section 5.4) and Content-Range (Section 5.2) | |||
header fields. An entity can be broken down into subranges according | header fields. An entity can be broken down into subranges according | |||
to various structural units. | to various structural units. | |||
range-unit = bytes-unit / other-range-unit | range-unit = bytes-unit / other-range-unit | |||
bytes-unit = "bytes" | bytes-unit = "bytes" | |||
other-range-unit = token | other-range-unit = token | |||
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 | ||||
implementations MAY ignore ranges specified using other units. | ||||
HTTP/1.1 has been designed to allow implementations of applications | HTTP/1.1 has been designed to allow implementations of applications | |||
that do not depend on knowledge of ranges. | that do not depend on knowledge of ranges. The only range unit | |||
defined by HTTP/1.1 is "bytes". | ||||
4. Status Code Definitions | If a range unit is not understood in a request, a server MUST ignore | |||
the whole Range header (Section 5.4). If a range unit is not | ||||
understood in a response, an intermediary SHOULD pass the response to | ||||
the client; a client MUST fail. | ||||
4.1. 206 Partial Content | 3. Status Code Definitions | |||
3.1. 206 Partial Content | ||||
The server has fulfilled the partial GET request for the resource. | The server has fulfilled the partial GET request for the resource. | |||
The request MUST have included a Range header field (Section 6.4) | The request MUST have included a Range header field (Section 5.4) | |||
indicating the desired range, and MAY have included an If-Range | indicating the desired range, and MAY have included an If-Range | |||
header field (Section 6.3) to make the request conditional. | header field (Section 5.3) to make the request conditional. | |||
The response MUST include the following header fields: | The response MUST include the following header fields: | |||
o Either a Content-Range header field (Section 6.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 ETag and/or Content-Location, if the header would have been sent | o ETag and/or Content-Location, if the header would have been sent | |||
in a 200 response to the same request | in a 200 response to the same request | |||
skipping to change at page 6, line 21 | skipping to change at page 6, line 37 | |||
differ from that sent in any previous response for the same | differ from that sent in any previous response for the same | |||
variant | variant | |||
If the 206 response is the result of an If-Range request, the | If the 206 response is the result of an If-Range request, the | |||
response SHOULD NOT include other entity-headers. Otherwise, the | response SHOULD NOT include other entity-headers. Otherwise, the | |||
response MUST include all of the entity-headers that would have been | response MUST include all of the entity-headers that would have been | |||
returned with a 200 (OK) response to the same request. | returned with a 200 (OK) response to the same request. | |||
A cache MUST NOT combine a 206 response with other previously cached | A cache MUST NOT combine a 206 response with other previously cached | |||
content if the ETag or Last-Modified headers do not match exactly, | content if the ETag or Last-Modified headers do not match exactly, | |||
see Section 5. | see Section 4. | |||
A cache that does not support the Range and Content-Range headers | A cache that does not support the Range and Content-Range headers | |||
MUST NOT cache 206 (Partial Content) responses. | MUST NOT cache 206 (Partial Content) responses. Furthermore, if a | |||
response uses a range unit that is not understood by the cache, then | ||||
it MUST NOT be cached either. | ||||
4.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 request-header field (Section 6.4), and none of the | included a Range request-header field (Section 5.4), and none of the | |||
ranges-specifier values in this field overlap the current extent of | ranges-specifier values in this field overlap the current extent of | |||
the selected resource, and the request did not include an If-Range | the selected resource, and the request did not include an If-Range | |||
request-header field. (For byte-ranges, this means that the first- | request-header field. (For byte-ranges, this means that the first- | |||
byte-pos of all of the byte-range-spec values were greater than the | byte-pos of all of the byte-range-spec values were greater than the | |||
current length of the selected resource.) | current length of the selected resource.) | |||
When this status code is returned for a byte-range request, the | When this status code is returned for a byte-range request, the | |||
response SHOULD include a Content-Range entity-header field | response SHOULD include a Content-Range entity-header field | |||
specifying the current length of the selected resource (see | specifying the current length of the selected resource (see | |||
Section 6.2). This response MUST NOT use the multipart/byteranges | Section 5.2). This response MUST NOT use the multipart/byteranges | |||
content-type. | content-type. | |||
5. Combining Byte Ranges | 4. Combining Ranges | |||
A response might transfer only a subrange of the bytes of an entity- | A response might transfer only a subrange of an entity-body, either | |||
body, either because the request included one or more Range | the request included one or more Range specifications, or because a | |||
specifications, or because a connection was broken prematurely. | connection was broken prematurely. After several such transfers, a | |||
After several such transfers, a cache might have received several | cache might have received several ranges of the same entity-body. | |||
ranges of the same entity-body. | ||||
If a cache has a stored non-empty set of subranges for an entity, and | If a cache has a stored non-empty set of subranges for an entity, and | |||
an incoming response transfers another subrange, the cache MAY | an incoming response transfers another subrange, the cache MAY | |||
combine the new subrange with the existing set if both the following | combine the new subrange with the existing set if both the following | |||
conditions are met: | conditions are met: | |||
o Both the incoming response and the cache entry have a cache | o Both the incoming response and the cache entry have a cache | |||
validator. | validator. | |||
o The two cache validators match using the strong comparison | o The two cache validators match using the strong comparison | |||
function (see Section 5 of [Part4]). | function (see Section 4 of [Part4]). | |||
If either requirement is not met, the cache MUST use only the most | If either requirement is not met, the cache MUST use only the most | |||
recent partial response (based on the Date values transmitted with | recent partial response (based on the Date values transmitted with | |||
every response, and using the incoming response if these values are | every response, and using the incoming response if these values are | |||
equal or missing), and MUST discard the other partial information. | equal or missing), and MUST discard the other partial information. | |||
6. Header Field Definitions | 5. Header Field Definitions | |||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
fields related to range requests and partial responses. | fields related to range requests and partial responses. | |||
For entity-header fields, both sender and recipient refer to either | For entity-header fields, both sender and recipient refer to either | |||
the client or the server, depending on who sends and who receives the | the client or the server, depending on who sends and who receives the | |||
entity. | entity. | |||
6.1. Accept-Ranges | 5.1. Accept-Ranges | |||
The response-header "Accept-Ranges" field allows the server to | The response-header "Accept-Ranges" field allows the server to | |||
indicate its acceptance of range requests for a resource: | indicate its acceptance of range requests for a resource: | |||
Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v | Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v | |||
Accept-Ranges-v = acceptable-ranges | Accept-Ranges-v = acceptable-ranges | |||
acceptable-ranges = 1#range-unit / "none" | acceptable-ranges = 1#range-unit / "none" | |||
Origin servers that accept byte-range requests MAY send | Origin servers that accept byte-range requests MAY send | |||
Accept-Ranges: bytes | Accept-Ranges: bytes | |||
but are not required to do so. Clients MAY generate byte-range | but are not required to do so. Clients MAY generate range requests | |||
requests without having received this header for the resource | without having received this header for the resource involved. Range | |||
involved. Range units are defined in Section 3. | units are defined in Section 2. | |||
Servers that do not accept any kind of range request for a resource | Servers that do not accept any kind of range request for a resource | |||
MAY send | MAY send | |||
Accept-Ranges: none | Accept-Ranges: none | |||
to advise the client not to attempt a range request. | to advise the client not to attempt a range request. | |||
6.2. Content-Range | 5.2. Content-Range | |||
The entity-header "Content-Range" is sent with a partial entity-body | The entity-header "Content-Range" is sent with a partial entity-body | |||
to specify where in the full entity-body the partial body should be | to specify where in the full entity-body the partial body should be | |||
applied. Range units are defined in Section 3. | applied. Range units are defined in Section 2. | |||
Content-Range = "Content-Range" ":" OWS Content-Range-v | Content-Range = "Content-Range" ":" OWS Content-Range-v | |||
Content-Range-v = content-range-spec | Content-Range-v = content-range-spec | |||
content-range-spec = byte-content-range-spec | content-range-spec = byte-content-range-spec | |||
/ other-content-range-spec | ||||
byte-content-range-spec = bytes-unit SP | byte-content-range-spec = bytes-unit SP | |||
byte-range-resp-spec "/" | byte-range-resp-spec "/" | |||
( instance-length / "*" ) | ( instance-length / "*" ) | |||
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | |||
/ "*" | / "*" | |||
instance-length = 1*DIGIT | instance-length = 1*DIGIT | |||
other-content-range-spec = other-range-unit SP | ||||
other-range-resp-spec | ||||
other-range-resp-spec = *CHAR | ||||
The header SHOULD indicate the total length of the full entity-body, | The header SHOULD indicate the total length of the full entity-body, | |||
unless this length is unknown or difficult to determine. The | unless this length is unknown or difficult to determine. The | |||
asterisk "*" character means that the instance-length is unknown at | asterisk "*" character means that the instance-length is unknown at | |||
the time when the response was generated. | the time when the response was generated. | |||
Unlike byte-ranges-specifier values (see Section 6.4.1), a byte- | Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- | |||
range-resp-spec MUST only specify one range, and MUST contain | range-resp-spec MUST only specify one range, and MUST contain | |||
absolute byte positions for both the first and last byte of the | absolute byte positions for both the first and last byte of the | |||
range. | range. | |||
A byte-content-range-spec with a byte-range-resp-spec whose last- | A byte-content-range-spec with a byte-range-resp-spec whose last- | |||
byte-pos value is less than its first-byte-pos value, or whose | byte-pos value is less than its first-byte-pos value, or whose | |||
instance-length value is less than or equal to its last-byte-pos | instance-length value is less than or equal to its last-byte-pos | |||
value, is invalid. The recipient of an invalid byte-content-range- | value, is invalid. The recipient of an invalid byte-content-range- | |||
spec MUST ignore it and any content transferred along with it. | spec MUST ignore it and any content transferred along with it. | |||
A server sending a response with status code 416 (Requested range not | In the case of a byte range request: A server sending a response with | |||
satisfiable) SHOULD include a Content-Range field with a byte-range- | status code 416 (Requested range not satisfiable) SHOULD include a | |||
resp-spec of "*". The instance-length specifies the current length | Content-Range field with a byte-range-resp-spec of "*". The | |||
of the selected resource. A response with status code 206 (Partial | instance-length specifies the current length of the selected resource | |||
as a decimal number. A response with status code 206 (Partial | ||||
Content) MUST NOT include a Content-Range field with a byte-range- | Content) MUST NOT include a Content-Range field with a byte-range- | |||
resp-spec of "*". | resp-spec of "*". | |||
Examples of byte-content-range-spec values, assuming that the entity | Examples of byte-content-range-spec values, assuming that the entity | |||
contains a total of 1234 bytes: | 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: | |||
bytes 500-999/1234 | bytes 500-999/1234 | |||
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: | |||
skipping to change at page 9, line 39 | skipping to change at page 10, line 12 | |||
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. See Appendix B.1 for a compatibility issue. | in Appendix A. See Appendix B.1 for a compatibility issue. | |||
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 byte- | 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 byte-ranges in one request, the | When a client requests multiple byte-ranges in one request, the | |||
server SHOULD return them in the order that they appeared in the | server SHOULD return them in the order that they appeared in the | |||
request. | request. | |||
If the server ignores a byte-range-spec because it is syntactically | If the server ignores a byte-range-spec because it is syntactically | |||
invalid, the server SHOULD treat the request as if the invalid Range | invalid, the server SHOULD treat the request as if the invalid Range | |||
header field did not exist. (Normally, this means return a 200 | header field did not exist. (Normally, this means return a 200 | |||
response containing the full entity). | response containing the full entity). | |||
If the server receives a request (other than one including an If- | If the server receives a request (other than one including an If- | |||
Range request-header field) with an unsatisfiable Range request- | Range request-header field) with an unsatisfiable Range request- | |||
header field (that is, all of whose byte-range-spec values have a | header field (that is, all of whose byte-range-spec values have a | |||
first-byte-pos value greater than the current length of the selected | first-byte-pos value greater than the current length of the selected | |||
resource), it SHOULD return a response code of 416 (Requested range | resource), it SHOULD return a response code of 416 (Requested range | |||
not satisfiable) (Section 4.2). | not satisfiable) (Section 3.2). | |||
Note: clients cannot depend on servers to send a 416 (Requested | Note: clients cannot depend on servers to send a 416 (Requested | |||
range not satisfiable) response instead of a 200 (OK) response for | range not satisfiable) response instead of a 200 (OK) response for | |||
an unsatisfiable Range request-header, since not all servers | an unsatisfiable Range request-header, since not all servers | |||
implement this request-header. | implement this request-header. | |||
6.3. If-Range | 5.3. If-Range | |||
If a client has a partial copy of an entity in its cache, and wishes | If a client has a partial copy of an entity in its cache, and wishes | |||
to have an up-to-date copy of the entire entity in its cache, it | to have an up-to-date copy of the entire entity in its cache, it | |||
could use the Range request-header with a conditional GET (using | could use the Range request-header with a conditional GET (using | |||
either or both of If-Unmodified-Since and If-Match.) However, if the | either or both of If-Unmodified-Since and If-Match.) However, if the | |||
condition fails because the entity has been modified, the client | condition fails because the entity has been modified, the client | |||
would then have to make a second request to obtain the entire current | would then have to make a second request to obtain the entire current | |||
entity-body. | entity-body. | |||
The request header "If-Range" allows a client to "short-circuit" the | The request header "If-Range" allows a client to "short-circuit" the | |||
skipping to change at page 10, line 47 | skipping to change at page 11, line 20 | |||
header SHOULD only be used together with a Range header, and MUST be | header SHOULD only be used together with a Range header, and MUST be | |||
ignored if the request does not include a Range header, or if the | ignored if the request does not include a Range header, or if the | |||
server does not support the sub-range operation. | server does not support the sub-range operation. | |||
If the entity tag given in the If-Range header matches the current | If the entity tag given in the If-Range header matches the current | |||
entity tag for the entity, then the server SHOULD provide the | entity tag for the entity, then the server SHOULD provide the | |||
specified sub-range of the entity using a 206 (Partial Content) | specified sub-range of the entity using a 206 (Partial Content) | |||
response. If the entity tag does not match, then the server SHOULD | response. If the entity tag does not match, then the server SHOULD | |||
return the entire entity using a 200 (OK) response. | return the entire entity using a 200 (OK) response. | |||
6.4. Range | 5.4. Range | |||
6.4.1. Byte Ranges | 5.4.1. Byte Ranges | |||
Since all HTTP entities are represented in HTTP messages as sequences | Since all HTTP entities are represented in HTTP messages as sequences | |||
of bytes, the concept of a byte range is meaningful for any HTTP | of bytes, the concept of a byte range is meaningful for any HTTP | |||
entity. (However, not all clients and servers need to support byte- | entity. (However, not all clients and servers need to support byte- | |||
range operations.) | range operations.) | |||
Byte range specifications in HTTP apply to the sequence of bytes in | Byte range specifications in HTTP apply to the sequence of bytes in | |||
the entity-body (not necessarily the same as the message-body). | the entity-body (not necessarily the same as the message-body). | |||
A byte range operation MAY specify a single range of bytes, or a set | A byte range operation MAY specify a single range of bytes, or a set | |||
of ranges within a single entity. | of ranges within a single entity. | |||
ranges-specifier = byte-ranges-specifier | ||||
byte-ranges-specifier = bytes-unit "=" byte-range-set | byte-ranges-specifier = bytes-unit "=" byte-range-set | |||
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | |||
byte-range-spec = first-byte-pos "-" [last-byte-pos] | byte-range-spec = first-byte-pos "-" [last-byte-pos] | |||
first-byte-pos = 1*DIGIT | first-byte-pos = 1*DIGIT | |||
last-byte-pos = 1*DIGIT | last-byte-pos = 1*DIGIT | |||
The first-byte-pos value in a byte-range-spec gives the byte-offset | The first-byte-pos value in a byte-range-spec gives the byte-offset | |||
of the first byte in a range. The last-byte-pos value gives the | of the first byte in a range. The last-byte-pos value gives the | |||
byte-offset of the last byte in the range; that is, the byte | byte-offset of the last byte in the range; that is, the byte | |||
positions specified are inclusive. Byte offsets start at zero. | positions specified are inclusive. Byte offsets are decimal and | |||
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 entity-body, last-byte-pos is | or equal to the current length of the entity-body, last-byte-pos is | |||
taken to be equal to one less than the current length of the entity- | taken to be equal to one less than the current length of the entity- | |||
body in bytes. | body 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 entity. | bytes retrieved without knowing the size of the entity. | |||
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 entity- | A suffix-byte-range-spec is used to specify the suffix of the entity- | |||
body, of a length given by the suffix-length value. (That is, this | body, of a length given by the decimal suffix-length value. (That | |||
form specifies the last N bytes of an entity-body.) If the entity is | is, this form specifies the last N bytes of an entity-body.) If the | |||
shorter than the specified suffix-length, the entire entity-body is | entity is shorter than the specified suffix-length, the entire | |||
used. | entity-body 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 entity-body, or at least one suffix-byte-range-spec with a non- | the entity-body, or at least one suffix-byte-range-spec with a non- | |||
zero suffix-length, then the byte-range-set is satisfiable. | 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 | set is unsatisfiable, the server SHOULD return a response with a | |||
status of 416 (Requested range not satisfiable). Otherwise, the | status of 416 (Requested range not satisfiable). Otherwise, the | |||
server SHOULD return a response with a status of 206 (Partial | server SHOULD return a response with a status of 206 (Partial | |||
Content) containing the satisfiable ranges of the entity-body. | Content) containing the satisfiable ranges of the entity-body. | |||
skipping to change at page 12, line 35 | skipping to change at page 13, line 5 | |||
o Or bytes=9500- | o Or bytes=9500- | |||
o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 | o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 | |||
o Several legal but not canonical specifications of the second 500 | o Several legal but not canonical specifications of the second 500 | |||
bytes (byte offsets 500-999, inclusive): | bytes (byte offsets 500-999, inclusive): | |||
bytes=500-600,601-999 | bytes=500-600,601-999 | |||
bytes=500-700,601-999 | bytes=500-700,601-999 | |||
6.4.2. Range Retrieval Requests | 5.4.2. Range Retrieval Requests | |||
HTTP retrieval requests using conditional or unconditional GET | HTTP retrieval requests using conditional or unconditional GET | |||
methods MAY request one or more sub-ranges of the entity, instead of | methods MAY request one or more sub-ranges of the entity, instead of | |||
the entire entity, using the Range request header, which applies to | the entire entity, using the Range request header, which applies to | |||
the entity returned as the result of the request: | the entity returned as the result of the request: | |||
Range = "Range" ":" OWS Range-v | Range = "Range" ":" OWS Range-v | |||
Range-v = ranges-specifier | Range-v = byte-ranges-specifier | |||
/ other-ranges-specifier | ||||
other-ranges-specifier = 1*CHAR | ||||
A server MAY ignore the Range header. However, HTTP/1.1 origin | A server MAY ignore the Range header. However, HTTP/1.1 origin | |||
servers and intermediate caches ought to support byte ranges when | servers and intermediate caches ought to support byte ranges when | |||
possible, since Range supports efficient recovery from partially | possible, since Range supports efficient recovery from partially | |||
failed transfers, and supports efficient partial retrieval of large | failed transfers, and supports efficient partial retrieval of large | |||
entities. | entities. | |||
If the server supports the Range header and the specified range or | If the server supports the Range header and the specified range or | |||
ranges are appropriate for the entity: | ranges are appropriate for the entity: | |||
skipping to change at page 13, line 18 | skipping to change at page 13, line 39 | |||
instead of 200 (OK). | instead of 200 (OK). | |||
o The presence of a Range header in a conditional GET (a request | o The presence of a Range header in a conditional GET (a request | |||
using one or both of If-Modified-Since and If-None-Match, or one | using one or both of If-Modified-Since and If-None-Match, or one | |||
or both of If-Unmodified-Since and If-Match) modifies what is | or both of If-Unmodified-Since and If-Match) modifies what is | |||
returned if the GET is otherwise successful and the condition is | returned if the GET is otherwise successful and the condition is | |||
true. It does not affect the 304 (Not Modified) response returned | true. It does not affect the 304 (Not Modified) response returned | |||
if the conditional is false. | if the conditional is false. | |||
In some cases, it might be more appropriate to use the If-Range | In some cases, it might be more appropriate to use the If-Range | |||
header (see Section 6.3) in addition to the Range header. | header (see Section 5.3) in addition to the Range header. | |||
If a proxy that supports ranges receives a Range request, forwards | If a proxy that supports ranges receives a Range request, forwards | |||
the request to an inbound server, and receives an entire entity in | the request to an inbound server, and receives an entire entity in | |||
reply, it SHOULD only return the requested range to its client. It | reply, it SHOULD only return the requested range to its client. It | |||
SHOULD store the entire received response in its cache if that is | SHOULD store the entire received response in its cache if that is | |||
consistent with its cache allocation policies. | consistent with its cache allocation policies. | |||
7. IANA Considerations | 6. IANA Considerations | |||
7.1. Message Header Registration | 6.1. Message Header Registration | |||
The Message Header Registry located at <http://www.iana.org/ | The Message Header Registry located at <http://www.iana.org/ | |||
assignments/message-headers/message-header-index.html> should be | assignments/message-headers/message-header-index.html> should be | |||
updated with the permanent registrations below (see [RFC3864]): | updated with the permanent registrations below (see [RFC3864]): | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Accept-Ranges | http | standard | Section 6.1 | | | Accept-Ranges | http | standard | Section 5.1 | | |||
| Content-Range | http | standard | Section 6.2 | | | Content-Range | http | standard | Section 5.2 | | |||
| If-Range | http | standard | Section 6.3 | | | If-Range | http | standard | Section 5.3 | | |||
| Range | http | standard | Section 6.4 | | | Range | http | standard | Section 5.4 | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
The change controller is: "IETF (iesg@ietf.org) - Internet | The change controller is: "IETF (iesg@ietf.org) - Internet | |||
Engineering Task Force". | Engineering Task Force". | |||
8. Security Considerations | 7. Security Considerations | |||
No additional security considerations have been identified beyond | No additional security considerations have been identified beyond | |||
those applicable to HTTP in general [Part1]. | those applicable to HTTP in general [Part1]. | |||
9. Acknowledgments | 8. Acknowledgments | |||
Most of the specification of ranges is based on work originally done | Most of the specification of ranges is based on work originally done | |||
by Ari Luotonen and John Franks, with additional input from Steve | by Ari Luotonen and John Franks, with additional input from Steve | |||
Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin | Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin | |||
Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, | Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, | |||
Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi | Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi | |||
Rizzo, and Bill Weihl. | Rizzo, and Bill Weihl. | |||
10. References | 9. References | |||
10.1. Normative References | 9.1. Normative References | |||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-05 | and Message Parsing", draft-ietf-httpbis-p1-messaging-06 | |||
(work in progress), November 2008. | (work in progress), March 2009. | |||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | |||
and Content Negotiation", draft-ietf-httpbis-p3-payload-05 | and Content Negotiation", draft-ietf-httpbis-p3-payload-06 | |||
(work in progress), November 2008. | (work in progress), March 2009. | |||
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | |||
Requests", draft-ietf-httpbis-p4-conditional-05 (work in | Requests", draft-ietf-httpbis-p4-conditional-06 (work in | |||
progress), November 2008. | progress), March 2009. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", | |||
draft-ietf-httpbis-p6-cache-05 (work in progress), | draft-ietf-httpbis-p6-cache-06 (work in progress), | |||
November 2008. | March 2009. | |||
[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. | |||
10.2. Informative References | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | ||||
9.2. Informative References | ||||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [RFC3864] 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. | |||
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | |||
skipping to change at page 17, line 18 | skipping to change at page 17, line 45 | |||
version documented in HTTP/1.1. | version documented in HTTP/1.1. | |||
Appendix B. Compatibility with Previous Versions | Appendix B. Compatibility with Previous Versions | |||
B.1. Changes from RFC 2068 | B.1. Changes from RFC 2068 | |||
Transfer-coding and message lengths all interact in ways that | Transfer-coding and message lengths all interact in ways that | |||
required fixing exactly when chunked encoding is used (to allow for | required fixing exactly when chunked encoding is used (to allow for | |||
transfer encoding that may not be self delimiting); it was important | transfer encoding that may not be self delimiting); it was important | |||
to straighten out exactly how message lengths are computed. | to straighten out exactly how message lengths are computed. | |||
(Section 6.2, see also [Part1], [Part3] and [Part6]) | (Section 5.2, see also [Part1], [Part3] and [Part6]) | |||
There are situations where a server (especially a proxy) does not | There are situations where a server (especially a proxy) does not | |||
know the full length of a response but is capable of serving a | know the full length of a response but is capable of serving a | |||
byterange request. We therefore need a mechanism to allow byteranges | byterange request. We therefore need a mechanism to allow byteranges | |||
with a content-range not indicating the full length of the message. | with a content-range not indicating the full length of the message. | |||
(Section 6.2) | ||||
(Section 5.2) | ||||
Range request responses would become very verbose if all meta-data | Range request responses would become very verbose if all meta-data | |||
were always returned; by allowing the server to only send needed | were always returned; by allowing the server to only send needed | |||
headers in a 206 response, this problem can be avoided. (Section 4.1 | headers in a 206 response, this problem can be avoided. (Section 3.1 | |||
and 6.3) | and 5.3) | |||
Fix problem with unsatisfiable range requests; there are two cases: | Fix problem with unsatisfiable range requests; there are two cases: | |||
syntactic problems, and range doesn't exist in the document. The 416 | syntactic problems, and range doesn't exist in the document. The 416 | |||
status code was needed to resolve this ambiguity needed to indicate | status code was needed to resolve this ambiguity needed to indicate | |||
an error for a byte range request that falls outside of the actual | an error for a byte range request that falls outside of the actual | |||
contents of a document. (Section 4.2, 6.2) | contents of a document. (Section 3.2, 5.2) | |||
B.2. Changes from RFC 2616 | B.2. Changes from RFC 2616 | |||
Clarify that it is not ok to use a weak cache validator in a 206 | Clarify that it is not ok to use a weak cache validator in a 206 | |||
response. (Section 4.1) | response. (Section 3.1) | |||
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. Change Log (to be removed by RFC Editor before publication) | Appendix C. Collected ABNF | |||
C.1. Since RFC2616 | Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v | |||
Accept-Ranges-v = acceptable-ranges | ||||
Content-Range = "Content-Range:" OWS Content-Range-v | ||||
Content-Range-v = content-range-spec | ||||
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> | ||||
If-Range = "If-Range:" OWS If-Range-v | ||||
If-Range-v = entity-tag / HTTP-date | ||||
OWS = <OWS, defined in [Part1], Section 1.2.2> | ||||
Range = "Range:" OWS Range-v | ||||
Range-v = byte-ranges-specifier / other-ranges-specifier | ||||
acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS | ||||
range-unit ] ) ) / "none" | ||||
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( | ||||
instance-length / "*" ) | ||||
byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" | ||||
byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( | ||||
suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / | ||||
suffix-byte-range-spec ] ) ) | ||||
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | ||||
byte-ranges-specifier = bytes-unit "=" byte-range-set | ||||
bytes-unit = "bytes" | ||||
content-range-spec = byte-content-range-spec / | ||||
other-content-range-spec | ||||
entity-tag = <entity-tag, defined in [Part4], Section 2> | ||||
first-byte-pos = 1*DIGIT | ||||
instance-length = 1*DIGIT | ||||
last-byte-pos = 1*DIGIT | ||||
other-content-range-spec = other-range-unit SP other-range-resp-spec | ||||
other-range-resp-spec = *CHAR | ||||
other-range-unit = token | ||||
other-ranges-specifier = 1*CHAR | ||||
range-unit = bytes-unit / other-range-unit | ||||
suffix-byte-range-spec = "-" suffix-length | ||||
suffix-length = 1*DIGIT | ||||
token = <token, defined in [Part1], Section 1.2.2> | ||||
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 RFC2616 | ||||
Extracted relevant partitions from [RFC2616]. | Extracted relevant partitions from [RFC2616]. | |||
C.2. Since draft-ietf-httpbis-p5-range-00 | D.2. Since draft-ietf-httpbis-p5-range-00 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache | o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache | |||
validators in 206 responses" | validators in 206 responses" | |||
(<http://purl.org/NET/http-errata#ifrange206>) | (<http://purl.org/NET/http-errata#ifrange206>) | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and | |||
Informative references" | Informative references" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- | o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- | |||
to-date references" | to-date references" | |||
C.3. Since draft-ietf-httpbis-p5-range-01 | D.3. Since draft-ietf-httpbis-p5-range-01 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to | |||
RFC4288" | RFC4288" | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Add explicit references to BNF syntax and rules imported from | o Add explicit references to BNF syntax and rules imported from | |||
other parts of the specification. | other parts of the specification. | |||
C.4. Since draft-ietf-httpbis-p5-range-02 | D.4. Since draft-ietf-httpbis-p5-range-02 | |||
Ongoing work on IANA Message Header Registration | Ongoing work on IANA Message Header Registration | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): | |||
o Reference RFC 3984, and update header registrations for headers | o Reference RFC 3984, and update header registrations for headers | |||
defined in this document. | defined in this document. | |||
C.5. Since draft-ietf-httpbis-p5-range-03 | D.5. Since draft-ietf-httpbis-p5-range-03 | |||
C.6. Since draft-ietf-httpbis-p5-range-04 | D.6. Since draft-ietf-httpbis-p5-range-04 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/ | o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/ | |||
byteranges minimum number of parts" | byteranges minimum number of parts" | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Use "/" instead of "|" for alternatives. | o Use "/" instead of "|" for alternatives. | |||
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | |||
whitespace ("OWS") and required whitespace ("RWS"). | whitespace ("OWS") and required whitespace ("RWS"). | |||
o Rewrite ABNFs to spell out whitespace rules, factor out header | o Rewrite ABNFs to spell out whitespace rules, factor out header | |||
value format definitions. | 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. | ||||
Index | Index | |||
2 | 2 | |||
206 Partial Content (status code) 5 | 206 Partial Content (status code) 6 | |||
4 | 4 | |||
416 Requested Range Not Satisfiable (status code) 6 | 416 Requested Range Not Satisfiable (status code) 6 | |||
A | A | |||
Accept-Ranges header 7 | Accept-Ranges header 7 | |||
C | C | |||
Content-Range header 8 | Content-Range header 8 | |||
skipping to change at page 19, line 47 | skipping to change at page 22, line 17 | |||
bytes-unit 5 | bytes-unit 5 | |||
Content-Range 8 | Content-Range 8 | |||
content-range-spec 8 | content-range-spec 8 | |||
Content-Range-v 8 | Content-Range-v 8 | |||
first-byte-pos 11 | first-byte-pos 11 | |||
If-Range 10 | If-Range 10 | |||
If-Range-v 10 | If-Range-v 10 | |||
instance-length 8 | instance-length 8 | |||
last-byte-pos 11 | last-byte-pos 11 | |||
other-range-unit 5 | other-range-unit 5 | |||
Range 12 | Range 13 | |||
range-unit 5 | range-unit 5 | |||
Range-v 12 | ||||
ranges-specifier 11 | ranges-specifier 11 | |||
suffix-byte-range-spec 11 | suffix-byte-range-spec 12 | |||
suffix-length 11 | suffix-length 12 | |||
H | H | |||
Headers | Headers | |||
Accept-Ranges 7 | Accept-Ranges 7 | |||
Content-Range 8 | Content-Range 8 | |||
If-Range 10 | If-Range 10 | |||
Range 10 | Range 11 | |||
I | I | |||
If-Range header 10 | If-Range header 10 | |||
M | M | |||
Media Type | Media Type | |||
multipart/byteranges 15 | multipart/byteranges 15 | |||
multipart/x-byteranges 17 | multipart/x-byteranges 17 | |||
multipart/byteranges Media Type 15 | multipart/byteranges Media Type 15 | |||
multipart/x-byteranges Media Type 17 | multipart/x-byteranges Media Type 17 | |||
R | R | |||
Range header 10 | Range header 11 | |||
S | S | |||
Status Codes | Status Codes | |||
206 Partial Content 5 | 206 Partial Content 6 | |||
416 Requested Range Not Satisfiable 6 | 416 Requested Range Not Satisfiable 6 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Day Software | Day Software | |||
23 Corporate Plaza DR, Suite 280 | 23 Corporate Plaza DR, Suite 280 | |||
Newport Beach, CA 92660 | Newport Beach, CA 92660 | |||
USA | USA | |||
skipping to change at page 23, line 4 | skipping to change at line 1095 | |||
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 | Phone: +49 251 2807760 | |||
Fax: +49 251 2807761 | 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/ | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
End of changes. 88 change blocks. | ||||
143 lines changed or deleted | 271 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |