draft-ietf-httpbis-p5-range-10.txt | draft-ietf-httpbis-p5-range-11.txt | |||
---|---|---|---|---|
HTTPbis 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 Alcatel-Lucent | Intended status: Standards Track Alcatel-Lucent | |||
Expires: January 13, 2011 J. Mogul | Expires: February 5, 2011 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 | |||
July 12, 2010 | August 4, 2010 | |||
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-10 | draft-ietf-httpbis-p5-range-11 | |||
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/3> and related | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix D.11. | The changes in this draft are summarized in Appendix D.12. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 13, 2011. | This Internet-Draft will expire on February 5, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.2.2. ABNF Rules defined in other Parts of the | 1.2.2. ABNF Rules defined in other Parts of the | |||
Specification . . . . . . . . . . . . . . . . . . . . 5 | Specification . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 | 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 | |||
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 | 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 | |||
4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8 | |||
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 | 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 | |||
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 | 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 | 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 | 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 | |||
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.2. Message Header Registration . . . . . . . . . . . . . . . 14 | 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
Appendix A. Internet Media Type multipart/byteranges . . . . . . 16 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | |||
Appendix B. Compatibility with Previous Versions . . . . . . . . 18 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 | |||
B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 18 | Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 | |||
B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 | Appendix B. Compatibility with Previous Versions . . . . . . . . 20 | |||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19 | B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 | |||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20 | ||||
Appendix D. Change Log (to be removed by RFC Editor before | Appendix D. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 20 | publication) . . . . . . . . . . . . . . . . . . . . 21 | |||
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20 | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21 | |||
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20 | D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21 | |||
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 20 | D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 | |||
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21 | D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 | |||
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21 | D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22 | |||
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21 | D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22 | |||
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21 | D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22 | |||
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22 | D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 | |||
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22 | D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23 | |||
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22 | D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23 | |||
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22 | D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | ||||
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 5, line 29 | skipping to change at page 6, line 29 | |||
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 6.1> | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | |||
entity-tag = <entity-tag, defined in [Part4], Section 2> | entity-tag = <entity-tag, defined in [Part4], Section 2> | |||
2. Range Units | 2. Range Units | |||
HTTP/1.1 allows a client to request that only part (a range of) the | HTTP/1.1 allows a client to request that only part (a range of) the | |||
response entity be included within the response. HTTP/1.1 uses range | representation be included within the response. HTTP/1.1 uses range | |||
units in the Range (Section 5.4) and Content-Range (Section 5.2) | units in the Range (Section 5.4) and Content-Range (Section 5.2) | |||
header fields. An entity can be broken down into subranges according | header fields. A representation can be broken down into subranges | |||
to various structural units. | according 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 | |||
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. The only range unit | that do not depend on knowledge of ranges. The only range unit | |||
defined by HTTP/1.1 is "bytes". | defined by HTTP/1.1 is "bytes". Additional specifiers can be defined | |||
as described in Section 2.1. | ||||
If a range unit is not understood in a request, a server MUST ignore | 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 | the whole Range header (Section 5.4). If a range unit is not | |||
understood in a response, an intermediary SHOULD pass the response to | understood in a response, an intermediary SHOULD pass the response to | |||
the client; a client MUST fail. | the client; a client MUST fail. | |||
2.1. Range Specifier Registry | ||||
The HTTP Ranger Specifier Registry defines the name space for the | ||||
range specifier names. | ||||
Registrations MUST include the following fields: | ||||
o Name | ||||
o Description | ||||
o Pointer to specification text | ||||
Values to be added to this name space are subject to IETF review | ||||
([RFC5226], Section 4.1). | ||||
The registry itself is maintained at | ||||
<http://www.iana.org/assignments/http-range-specifiers>. | ||||
3. Status Code Definitions | 3. Status Code Definitions | |||
3.1. 206 Partial Content | 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 5.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 5.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 5.2) indicating the | o Either a Content-Range header field (Section 5.2) indicating the | |||
skipping to change at page 6, line 17 | skipping to change at page 7, line 34 | |||
The request MUST have included a Range header field (Section 5.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 5.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 5.2) indicating the | o Either a Content-Range header field (Section 5.2) indicating the | |||
range included with this response, or a multipart/byteranges | range included with this response, or a multipart/byteranges | |||
Content-Type including Content-Range fields for each part. If a | Content-Type including Content-Range fields for each part. If a | |||
Content-Length header field is present in the response, its value | Content-Length header field is present in the response, its value | |||
MUST match the actual number of OCTETs transmitted in the message- | MUST match the actual number of octets transmitted in the message- | |||
body. | body. | |||
o Date | o Date | |||
o ETag and/or Content-Location, if the header would have been sent | o Cache-Control, ETag, Expires, Content-Location, Last-Modified, | |||
in a 200 response to the same request | and/or Vary, if the header field would have been sent in a 200 | |||
response to the same request | ||||
o Expires, Cache-Control, and/or Vary, if the field-value might | ||||
differ from that sent in any previous response for the same | ||||
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 representation header fields. | |||
response MUST include all of the entity-headers that would have been | Otherwise, the response MUST include all of the representation header | |||
returned with a 200 (OK) response to the same request. | fields that would have been returned with a 200 (OK) response to the | |||
same request. | ||||
A cache MUST NOT combine a 206 response with other previously cached | A cache MUST NOT combine a 206 response with other previously cached | |||
content if the ETag or Last-Modified headers do not match exactly, | content if the ETag or Last-Modified headers do not match exactly, | |||
see Section 4. | see Section 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. Furthermore, if a | MUST NOT cache 206 (Partial Content) responses. Furthermore, if a | |||
response uses a range unit that is not understood by the cache, then | response uses a range unit that is not understood by the cache, then | |||
it MUST NOT be cached either. | it MUST NOT be cached either. | |||
skipping to change at page 7, line 4 | skipping to change at page 8, line 19 | |||
3.2. 416 Requested Range Not Satisfiable | 3.2. 416 Requested Range Not Satisfiable | |||
A server SHOULD return a response with this status code if a request | A server SHOULD return a response with this status code if a request | |||
included a Range request-header field (Section 5.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 (Section 5.3). (For byte-ranges, this means | request-header field (Section 5.3). (For byte-ranges, this means | |||
that the first-byte-pos of all of the byte-range-spec values were | that the first-byte-pos of all of the byte-range-spec values were | |||
greater than the current length of the selected resource.) | greater than the 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 header field specifying the | |||
specifying the current length of the selected resource (see | current length of the representation (see Section 5.2). This | |||
Section 5.2). This response MUST NOT use the multipart/byteranges | response MUST NOT use the multipart/byteranges content-type. | |||
content-type. | ||||
4. Combining Ranges | 4. Combining Ranges | |||
A response might transfer only a subrange of an entity-body, either | A response might transfer only a subrange of a representation, either | |||
because the request included one or more Range specifications, or | because the request included one or more Range specifications, or | |||
because a connection was broken prematurely. After several such | because a connection closed prematurely. After several such | |||
transfers, a cache might have received several ranges of the same | transfers, a cache might have received several ranges of the same | |||
entity-body. | representation. | |||
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 a | |||
an incoming response transfers another subrange, the cache MAY | representation, and an incoming response transfers another subrange, | |||
combine the new subrange with the existing set if both the following | the cache MAY combine the new subrange with the existing set if both | |||
conditions are met: | the following conditions are met: | |||
o Both the incoming response and the cache entry have a cache | o Both the incoming response and the cache entry have a cache | |||
validator. | validator. | |||
o The two cache validators match using the strong comparison | o The two cache validators match using the strong comparison | |||
function (see Section 4 of [Part4]). | function (see Section 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. | |||
5. 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 | ||||
the client or the server, depending on who sends and who receives the | ||||
entity. | ||||
5.1. Accept-Ranges | 5.1. Accept-Ranges | |||
The "Accept-Ranges" response-header field allows a resource to | The "Accept-Ranges" response-header field allows a resource to | |||
indicate its acceptance of range requests. | indicate its acceptance of range requests. | |||
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 | |||
skipping to change at page 8, line 22 | skipping to change at page 9, line 31 | |||
Servers that do not accept any kind of range request for a resource | Servers that do not accept any kind of range request for a resource | |||
MAY send | MAY send | |||
Accept-Ranges: none | Accept-Ranges: none | |||
to advise the client not to attempt a range request. | to advise the client not to attempt a range request. | |||
5.2. Content-Range | 5.2. Content-Range | |||
The "Content-Range" entity-header field is sent with a partial | The "Content-Range" header field is sent with a partial | |||
entity-body to specify where in the full entity-body the partial body | representation to specify where in the full representation the | |||
should be applied. Range units are defined in Section 2. | payload body is intended to be 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 | / 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 / "*" ) | |||
skipping to change at page 8, line 42 | skipping to change at page 10, line 4 | |||
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-content-range-spec = other-range-unit SP | |||
other-range-resp-spec | other-range-resp-spec | |||
other-range-resp-spec = *CHAR | 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 | |||
unless this length is unknown or difficult to determine. The | representation, unless this length is unknown or difficult to | |||
asterisk "*" character means that the instance-length is unknown at | determine. The asterisk "*" character means that the instance-length | |||
the time when the response was generated. | is unknown at the time when the response was generated. | |||
Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- | Unlike byte-ranges-specifier values (see Section 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. | |||
In the case of a byte range request: A server sending a response with | In the case of a byte range request: A server sending a response with | |||
status code 416 (Requested range not satisfiable) SHOULD include a | status code 416 (Requested range not satisfiable) SHOULD include a | |||
Content-Range field with a byte-range-resp-spec of "*". The | Content-Range field with a byte-range-resp-spec of "*". The | |||
instance-length specifies the current length of the selected | instance-length specifies the current length of the selected | |||
resource. A response with status code 206 (Partial Content) MUST NOT | resource. A response with status code 206 (Partial Content) MUST NOT | |||
include a Content-Range field with a byte-range-resp-spec of "*". | include a Content-Range field with a byte-range-resp-spec of "*". | |||
Examples of byte-content-range-spec values, assuming that the entity | Examples of byte-content-range-spec values, assuming that the | |||
contains a total of 1234 bytes: | representation contains a total of 1234 bytes: | |||
o The first 500 bytes: | o The first 500 bytes: | |||
bytes 0-499/1234 | bytes 0-499/1234 | |||
o The second 500 bytes: | o The second 500 bytes: | |||
bytes 500-999/1234 | bytes 500-999/1234 | |||
o All except for the first 500 bytes: | o All except for the first 500 bytes: | |||
skipping to change at page 10, line 5 | skipping to change at page 11, line 17 | |||
Date: Wed, 15 Nov 1995 06:25:24 GMT | Date: Wed, 15 Nov 1995 06:25:24 GMT | |||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |||
Content-Range: bytes 21010-47021/47022 | Content-Range: bytes 21010-47021/47022 | |||
Content-Length: 26012 | Content-Length: 26012 | |||
Content-Type: image/gif | Content-Type: image/gif | |||
When an HTTP message includes the content of multiple ranges (for | When an HTTP message includes the content of multiple ranges (for | |||
example, a response to a request for multiple non-overlapping | example, a response to a request for multiple non-overlapping | |||
ranges), these are transmitted as a multipart message. The multipart | ranges), these are transmitted as a multipart message. The multipart | |||
media type used for this purpose is "multipart/byteranges" as defined | media type used for this purpose is "multipart/byteranges" as defined | |||
in Appendix A. See Appendix B.1 for a compatibility issue. | in Appendix A. | |||
A response to a request for a single range MUST NOT be sent using the | A response to a request for a single range MUST NOT be sent using the | |||
multipart/byteranges media type. A response to a request for | multipart/byteranges media type. A response to a request for | |||
multiple ranges, whose result is a single range, MAY be sent as a | multiple ranges, whose result is a single range, MAY be sent as a | |||
multipart/byteranges media type with one part. A client that cannot | multipart/byteranges media type with one part. A client that cannot | |||
decode a multipart/byteranges message MUST NOT ask for multiple | decode a multipart/byteranges message MUST NOT ask for multiple | |||
ranges in a single request. | ranges in a single request. | |||
When a client requests multiple ranges in one request, the server | When a client requests multiple ranges in one request, the server | |||
SHOULD return them in the order that they appeared in the request. | SHOULD return them in the order that they appeared in the request. | |||
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 representation). | |||
If the server receives a request (other than one including an If- | If the server receives a request (other than one including an If- | |||
Range request-header field) with an unsatisfiable Range request- | Range request-header field) with an unsatisfiable Range request- | |||
header field (that is, all of whose byte-range-spec values have a | header field (that is, all of whose byte-range-spec values have a | |||
first-byte-pos value greater than the current length of the selected | first-byte-pos value greater than the current length of the selected | |||
resource), it SHOULD return a response code of 416 (Requested range | resource), it SHOULD return a response code of 416 (Requested range | |||
not satisfiable) (Section 3.2). | not satisfiable) (Section 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. | |||
5.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 a representation in its cache, and | |||
to have an up-to-date copy of the entire entity in its cache, it | wishes to have an up-to-date copy of the entire representation in its | |||
could use the Range request-header with a conditional GET (using | cache, it could use the Range request-header with a conditional GET | |||
either or both of If-Unmodified-Since and If-Match.) However, if the | (using either or both of If-Unmodified-Since and If-Match.) However, | |||
condition fails because the entity has been modified, the client | if the condition fails because the representation has been modified, | |||
would then have to make a second request to obtain the entire current | the client would then have to make a second request to obtain the | |||
entity-body. | entire current representation. | |||
The "If-Range" request-header field allows a client to "short- | The "If-Range" request-header field allows a client to "short- | |||
circuit" the second request. Informally, its meaning is "if the | circuit" the second request. Informally, its meaning is "if the | |||
entity is unchanged, send me the part(s) that I am missing; | representation is unchanged, send me the part(s) that I am missing; | |||
otherwise, send me the entire new entity". | otherwise, send me the entire new representation". | |||
If-Range = "If-Range" ":" OWS If-Range-v | If-Range = "If-Range" ":" OWS If-Range-v | |||
If-Range-v = entity-tag / HTTP-date | If-Range-v = entity-tag / HTTP-date | |||
If the client has no entity tag for an entity, but does have a Last- | If the client has no entity-tag for a representation, but does have a | |||
Modified date, it MAY use that date in an If-Range header. (The | Last-Modified date, it MAY use that date in an If-Range header. (The | |||
server can distinguish between a valid HTTP-date and any form of | server can distinguish between a valid HTTP-date and any form of | |||
entity-tag by examining no more than two characters.) The If-Range | entity-tag by examining no more than two characters.) The If-Range | |||
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 | |||
cache validator for the entity, then the server SHOULD provide the | cache validator for the representation, then the server SHOULD | |||
specified sub-range of the entity using a 206 (Partial Content) | provide the specified sub-range of the representation using a 206 | |||
response. If the cache validator does not match, then the server | (Partial Content) response. If the cache validator does not match, | |||
SHOULD return the entire entity using a 200 (OK) response. | then the server SHOULD return the entire representation using a 200 | |||
(OK) response. | ||||
5.4. Range | 5.4. Range | |||
5.4.1. Byte Ranges | 5.4.1. Byte Ranges | |||
Since all HTTP entities are represented in HTTP messages as sequences | Since all HTTP representations are transferred as sequences of bytes, | |||
of bytes, the concept of a byte range is meaningful for any HTTP | the concept of a byte range is meaningful for any HTTP | |||
entity. (However, not all clients and servers need to support byte- | representation. (However, not all clients and servers need to | |||
range operations.) | support byte-range operations.) | |||
Byte range specifications in HTTP apply to the sequence of bytes in | Byte range specifications in HTTP apply to the sequence of bytes in | |||
the entity-body (not necessarily the same as the message-body). | the representation 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 representation. | |||
byte-ranges-specifier = bytes-unit "=" byte-range-set | byte-ranges-specifier = bytes-unit "=" byte-range-set | |||
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | |||
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | |||
first-byte-pos = 1*DIGIT | first-byte-pos = 1*DIGIT | |||
last-byte-pos = 1*DIGIT | last-byte-pos = 1*DIGIT | |||
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 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 representation body, last-byte- | |||
taken to be equal to one less than the current length of the entity- | pos is taken to be equal to one less than the current length of the | |||
body in bytes. | representation in bytes. | |||
By its choice of last-byte-pos, a client can limit the number of | By its choice of last-byte-pos, a client can limit the number of | |||
bytes retrieved without knowing the size of the entity. | bytes retrieved without knowing the size of the representation. | |||
suffix-byte-range-spec = "-" suffix-length | suffix-byte-range-spec = "-" suffix-length | |||
suffix-length = 1*DIGIT | suffix-length = 1*DIGIT | |||
A suffix-byte-range-spec is used to specify the suffix of the entity- | A suffix-byte-range-spec is used to specify the suffix of the | |||
body, of a length given by the suffix-length value. (That is, this | representation body, of a length given by the suffix-length value. | |||
form specifies the last N bytes of an entity-body.) If the entity is | (That is, this form specifies the last N bytes of a representation.) | |||
shorter than the specified suffix-length, the entire entity-body is | If the representation is shorter than the specified suffix-length, | |||
used. | the entire representation is used. | |||
If a syntactically valid byte-range-set includes at least one byte- | If a syntactically valid byte-range-set includes at least one byte- | |||
range-spec whose first-byte-pos is less than the current length of | range-spec whose first-byte-pos is less than the current length of | |||
the entity-body, or at least one suffix-byte-range-spec with a non- | the 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. 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 416 | |||
status of 416 (Requested range not satisfiable). Otherwise, the | (Requested range not satisfiable) status code. Otherwise, the server | |||
server SHOULD return a response with a status of 206 (Partial | SHOULD return a response with a 206 (Partial Content) status code | |||
Content) containing the satisfiable ranges of the entity-body. | containing the satisfiable ranges of the representation. | |||
Examples of byte-ranges-specifier values (assuming an entity-body of | Examples of byte-ranges-specifier values (assuming a representation | |||
length 10000): | of length 10000): | |||
o The first 500 bytes (byte offsets 0-499, inclusive): | o The first 500 bytes (byte offsets 0-499, inclusive): | |||
bytes=0-499 | bytes=0-499 | |||
o The second 500 bytes (byte offsets 500-999, inclusive): | o The second 500 bytes (byte offsets 500-999, inclusive): | |||
bytes=500-999 | bytes=500-999 | |||
o The final 500 bytes (byte offsets 9500-9999, inclusive): | o The final 500 bytes (byte offsets 9500-9999, inclusive): | |||
skipping to change at page 13, line 14 | skipping to change at page 14, line 30 | |||
o Several legal but not canonical specifications of the second 500 | o Several legal but not canonical specifications of the second 500 | |||
bytes (byte offsets 500-999, inclusive): | bytes (byte offsets 500-999, inclusive): | |||
bytes=500-600,601-999 | bytes=500-600,601-999 | |||
bytes=500-700,601-999 | bytes=500-700,601-999 | |||
5.4.2. Range Retrieval Requests | 5.4.2. Range Retrieval Requests | |||
The "Range" request-header field defines the GET method (conditional | The "Range" request-header field defines the GET method (conditional | |||
or not) to request one or more sub-ranges of the response entity- | or not) to request one or more sub-ranges of the response | |||
body, instead of the entire entity body. | representation body, instead of the entire representation body. | |||
Range = "Range" ":" OWS Range-v | Range = "Range" ":" OWS Range-v | |||
Range-v = byte-ranges-specifier | Range-v = byte-ranges-specifier | |||
/ other-ranges-specifier | / other-ranges-specifier | |||
other-ranges-specifier = other-range-unit "=" other-range-set | other-ranges-specifier = other-range-unit "=" other-range-set | |||
other-range-set = 1*CHAR | other-range-set = 1*CHAR | |||
A server MAY ignore the Range header. 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. | representations. | |||
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 representation: | |||
o The presence of a Range header in an unconditional GET modifies | o The presence of a Range header in an unconditional GET modifies | |||
what is returned if the GET is otherwise successful. In other | what is returned if the GET is otherwise successful. In other | |||
words, the response carries a status code of 206 (Partial Content) | words, the response carries a status code of 206 (Partial Content) | |||
instead of 200 (OK). | instead of 200 (OK). | |||
o The presence of a Range header in a conditional GET (a request | o The presence of a Range header in a conditional GET (a request | |||
using one or both of If-Modified-Since and If-None-Match, or one | using one or both of If-Modified-Since and If-None-Match, or one | |||
or both of If-Unmodified-Since and If-Match) modifies what is | or both of If-Unmodified-Since and If-Match) modifies what is | |||
returned if the GET is otherwise successful and the condition is | returned if the GET is otherwise successful and the condition is | |||
true. It does not affect the 304 (Not Modified) response returned | true. It does not affect the 304 (Not Modified) response returned | |||
if the conditional is false. | if the conditional is false. | |||
In some cases, it might be more appropriate to use the If-Range | In some cases, it might be more appropriate to use the If-Range | |||
header (see Section 5.3) in addition to the Range header. | header (see Section 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 | |||
reply, it SHOULD only return the requested range to its client. It | representation in reply, it SHOULD only return the requested range to | |||
SHOULD store the entire received response in its cache if that is | its client. It SHOULD store the entire received response in its | |||
consistent with its cache allocation policies. | cache if that is consistent with its cache allocation policies. | |||
6. IANA Considerations | 6. IANA Considerations | |||
6.1. Status Code Registration | 6.1. Status Code Registration | |||
The HTTP Status Code Registry located at | The HTTP Status Code Registry located at | |||
<http://www.iana.org/assignments/http-status-codes> should be updated | <http://www.iana.org/assignments/http-status-codes> shall be updated | |||
with the registrations below: | with the registrations below: | |||
+-------+---------------------------------+-------------+ | +-------+---------------------------------+-------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+---------------------------------+-------------+ | +-------+---------------------------------+-------------+ | |||
| 206 | Partial Content | Section 3.1 | | | 206 | Partial Content | Section 3.1 | | |||
| 416 | Requested Range Not Satisfiable | Section 3.2 | | | 416 | Requested Range Not Satisfiable | Section 3.2 | | |||
+-------+---------------------------------+-------------+ | +-------+---------------------------------+-------------+ | |||
6.2. Message Header Registration | 6.2. Header Field Registration | |||
The Message Header Registry located at <http://www.iana.org/ | The Message Header Field Registry located at <http://www.iana.org/ | |||
assignments/message-headers/message-header-index.html> should be | assignments/message-headers/message-header-index.html> shall 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 5.1 | | | Accept-Ranges | http | standard | Section 5.1 | | |||
| Content-Range | http | standard | Section 5.2 | | | Content-Range | http | standard | Section 5.2 | | |||
| If-Range | http | standard | Section 5.3 | | | If-Range | http | standard | Section 5.3 | | |||
| Range | http | standard | Section 5.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". | |||
6.3. Range Specifier Registration | ||||
The registration procedure for HTTP Range Specifiers is defined by | ||||
Section 2.1 of this document. | ||||
The HTTP Range Specifier Registry shall be created at | ||||
<http://www.iana.org/assignments/http-range-specifiers> and be | ||||
populated with the registrations below: | ||||
+----------------------+-------------------+----------------------+ | ||||
| Range Specifier Name | Description | Reference | | ||||
+----------------------+-------------------+----------------------+ | ||||
| bytes | a range of octets | (this specification) | | ||||
+----------------------+-------------------+----------------------+ | ||||
The change controller is: "IETF (iesg@ietf.org) - Internet | ||||
Engineering Task Force". | ||||
7. 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]. | |||
8. 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 | |||
skipping to change at page 15, line 4 | skipping to change at page 16, line 38 | |||
8. 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. | |||
9. References | 9. References | |||
9.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-10 | and Message Parsing", draft-ietf-httpbis-p1-messaging-11 | |||
(work in progress), July 2010. | (work in progress), August 2010. | |||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | ||||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | ||||
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | ||||
and Content Negotiation", draft-ietf-httpbis-p3-payload-10 | ||||
(work in progress), July 2010. | ||||
[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-10 (work in | Requests", draft-ietf-httpbis-p4-conditional-11 (work in | |||
progress), July 2010. | progress), August 2010. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | ||||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | ||||
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | ||||
6: Caching", draft-ietf-httpbis-p6-cache-10 (work in | ||||
progress), July 2010. | ||||
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part Two: Media Types", RFC 2046, | Extensions (MIME) Part Two: Media Types", RFC 2046, | |||
November 1996. | November 1996. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
skipping to change at page 16, line 5 | skipping to change at page 17, line 28 | |||
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 | |||
Registration Procedures", BCP 13, RFC 4288, December 2005. | Registration Procedures", BCP 13, RFC 4288, December 2005. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
Appendix A. Internet Media Type multipart/byteranges | Appendix A. Internet Media Type multipart/byteranges | |||
When an HTTP 206 (Partial Content) response message includes the | When an HTTP 206 (Partial Content) response message includes the | |||
content of multiple ranges (a response to a request for multiple non- | content of multiple ranges (a response to a request for multiple non- | |||
overlapping ranges), these are transmitted as a multipart message- | overlapping ranges), these are transmitted as a multipart message- | |||
body ([RFC2046], Section 5.1). The media type for this purpose is | body ([RFC2046], Section 5.1). The media type for this purpose is | |||
called "multipart/byteranges". The following is to be registered | called "multipart/byteranges". The following is to be registered | |||
with IANA [RFC4288]. | with IANA [RFC4288]. | |||
Note: Despite the name "multipart/byteranges" is not limited to | Note: Despite the name "multipart/byteranges" is not limited to | |||
skipping to change at page 18, line 5 | skipping to change at page 19, line 44 | |||
...the first range... | ...the first range... | |||
--THIS_STRING_SEPARATES | --THIS_STRING_SEPARATES | |||
Content-type: video/example | Content-type: video/example | |||
Content-range: exampleunit 11.2-14.3/25 | Content-range: exampleunit 11.2-14.3/25 | |||
...the second range | ...the second range | |||
--THIS_STRING_SEPARATES-- | --THIS_STRING_SEPARATES-- | |||
Notes: | Notes: | |||
1. Additional CRLFs may precede the first boundary string in the | 1. Additional CRLFs MAY precede the first boundary string in the | |||
entity. | body. | |||
2. Although [RFC2046] permits the boundary string to be quoted, some | 2. Although [RFC2046] permits the boundary string to be quoted, some | |||
existing implementations handle a quoted boundary string | existing implementations handle a quoted boundary string | |||
incorrectly. | incorrectly. | |||
3. A number of browsers and servers were coded to an early draft of | 3. A number of browsers and servers were coded to an early draft of | |||
the byteranges specification to use a media type of multipart/ | the byteranges specification to use a media type of multipart/ | |||
x-byteranges, which is almost, but not quite compatible with the | x-byteranges, which is almost, but not quite compatible with the | |||
version documented in HTTP/1.1. | version documented in HTTP/1.1. | |||
Appendix B. Compatibility with Previous Versions | Appendix B. Compatibility with Previous Versions | |||
B.1. Changes from RFC 2068 | B.1. Changes from RFC 2616 | |||
Transfer-coding and message lengths all interact in ways that | ||||
required fixing exactly when chunked encoding is used (to allow for | ||||
transfer encoding that may not be self delimiting); it was important | ||||
to straighten out exactly how message lengths are computed. | ||||
(Section 5.2, see also [Part1], [Part3] and [Part6]) | ||||
There are situations where a server (especially a proxy) does not | ||||
know the full length of a response but is capable of serving a | ||||
byterange request. We therefore need a mechanism to allow byteranges | ||||
with a content-range not indicating the full length of the message. | ||||
(Section 5.2) | ||||
Range request responses would become very verbose if all meta-data | ||||
were always returned; by allowing the server to only send needed | ||||
headers in a 206 response, this problem can be avoided. (Section 3.1 | ||||
and 5.3) | ||||
Fix problem with unsatisfiable range requests; there are two cases: | ||||
syntactic problems, and range doesn't exist in the document. The 416 | ||||
status code was needed to resolve this ambiguity needed to indicate | ||||
an error for a byte range request that falls outside of the actual | ||||
contents of a document. (Section 3.2, 5.2) | ||||
B.2. Changes from RFC 2616 | ||||
Clarify that it is not ok to use a weak cache validator in a 206 | Clarify that it is not ok to use a weak cache validator in a 206 | |||
response. (Section 3.1) | response. (Section 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. Collected ABNF | Appendix C. Collected ABNF | |||
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 | |||
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 | |||
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | |||
If-Range = "If-Range:" OWS If-Range-v | If-Range = "If-Range:" OWS If-Range-v | |||
If-Range-v = entity-tag / HTTP-date | If-Range-v = entity-tag / HTTP-date | |||
skipping to change at page 22, line 36 | skipping to change at page 23, line 47 | |||
registrations for optional status codes" | registrations for optional status codes" | |||
D.10. Since draft-ietf-httpbis-p5-range-08 | D.10. Since draft-ietf-httpbis-p5-range-08 | |||
No significant changes. | No significant changes. | |||
D.11. Since draft-ietf-httpbis-p5-range-09 | D.11. Since draft-ietf-httpbis-p5-range-09 | |||
No significant changes. | No significant changes. | |||
D.12. Since draft-ietf-httpbis-p5-range-10 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify | ||||
'Requested Variant'" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify | ||||
entity / representation / variant terminology" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider | ||||
removing the 'changes from 2068' sections" | ||||
Ongoing work on Custom Ranges | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>): | ||||
o Add IANA registry. | ||||
Index | Index | |||
2 | 2 | |||
206 Partial Content (status code) 6 | 206 Partial Content (status code) 7 | |||
4 | 4 | |||
416 Requested Range Not Satisfiable (status code) 6 | 416 Requested Range Not Satisfiable (status code) 8 | |||
A | A | |||
Accept-Ranges header 7 | Accept-Ranges header 9 | |||
C | C | |||
Content-Range header 8 | Content-Range header 9 | |||
G | G | |||
Grammar | Grammar | |||
Accept-Ranges 7 | Accept-Ranges 9 | |||
Accept-Ranges-v 7 | Accept-Ranges-v 9 | |||
acceptable-ranges 7 | acceptable-ranges 9 | |||
byte-content-range-spec 8 | byte-content-range-spec 9 | |||
byte-range-resp-spec 8 | byte-range-resp-spec 9 | |||
byte-range-set 11 | byte-range-set 12 | |||
byte-range-spec 11 | byte-range-spec 12 | |||
byte-ranges-specifier 11 | byte-ranges-specifier 12 | |||
bytes-unit 5 | bytes-unit 6 | |||
Content-Range 8 | Content-Range 9 | |||
content-range-spec 8 | content-range-spec 9 | |||
Content-Range-v 8 | Content-Range-v 9 | |||
first-byte-pos 11 | first-byte-pos 12 | |||
If-Range 10 | If-Range 12 | |||
If-Range-v 10 | If-Range-v 12 | |||
instance-length 8 | instance-length 9 | |||
last-byte-pos 11 | last-byte-pos 12 | |||
other-range-unit 5 | other-range-unit 6 | |||
Range 13 | Range 14 | |||
range-unit 5 | range-unit 6 | |||
ranges-specifier 11 | ranges-specifier 12 | |||
suffix-byte-range-spec 12 | suffix-byte-range-spec 13 | |||
suffix-length 12 | suffix-length 13 | |||
H | H | |||
Headers | Headers | |||
Accept-Ranges 7 | Accept-Ranges 9 | |||
Content-Range 8 | Content-Range 9 | |||
If-Range 10 | If-Range 11 | |||
Range 11 | Range 12 | |||
I | I | |||
If-Range header 10 | If-Range header 11 | |||
M | M | |||
Media Type | Media Type | |||
multipart/byteranges 16 | multipart/byteranges 17 | |||
multipart/x-byteranges 18 | multipart/x-byteranges 20 | |||
multipart/byteranges Media Type 16 | multipart/byteranges Media Type 17 | |||
multipart/x-byteranges Media Type 18 | multipart/x-byteranges Media Type 20 | |||
R | R | |||
Range header 11 | Range header 12 | |||
S | S | |||
Status Codes | Status Codes | |||
206 Partial Content 6 | 206 Partial Content 7 | |||
416 Requested Range Not Satisfiable 6 | 416 Requested Range Not Satisfiable 8 | |||
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 | |||
Phone: +1-949-706-5300 | Phone: +1-949-706-5300 | |||
End of changes. 68 change blocks. | ||||
222 lines changed or deleted | 250 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/ |