draft-ietf-httpbis-p5-range-21.txt | draft-ietf-httpbis-p5-range-22.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 2616 (if approved) Y. Lafon, Ed. | Obsoletes: 2616 (if approved) Y. Lafon, Ed. | |||
Intended status: Standards Track W3C | Intended status: Standards Track W3C | |||
Expires: April 7, 2013 J. Reschke, Ed. | Expires: August 27, 2013 J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
October 4, 2012 | February 23, 2013 | |||
Hypertext Transfer Protocol (HTTP/1.1): Range Requests | Hypertext Transfer Protocol (HTTP/1.1): Range Requests | |||
draft-ietf-httpbis-p5-range-21 | draft-ietf-httpbis-p5-range-22 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypertext information | protocol for distributed, collaborative, hypertext information | |||
systems. This document defines range requests and the rules for | systems. This document defines range requests and the rules for | |||
constructing and combining responses to those requests. | constructing and combining responses to those requests. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft takes place on the HTTPBIS working group | Discussion of this draft takes place on the HTTPBIS working group | |||
mailing list (ietf-http-wg@w3.org), which is archived at | mailing list (ietf-http-wg@w3.org), which is archived at | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
The current issues list is at | The current issues list is at | |||
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix E.2. | The changes in this draft are summarized in Appendix E.3. | |||
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 April 7, 2013. | This Internet-Draft will expire on August 27, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2013 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 3, line 11 | skipping to change at page 3, line 11 | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5 | 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 | 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5 | 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 | 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7 | 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.1. Response to a Single and Multiple Ranges Request . . . . . 7 | 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 7 | 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9 | |||
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 | 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 | |||
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8 | 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 | 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 | |||
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 | 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 | |||
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 | 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 | |||
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 | |||
6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 | |||
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | 6.1. Denial of Service Attacks using Range . . . . . . . . . . 17 | |||
7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 | Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 | |||
Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 | |||
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 19 | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 | |||
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 19 | ||||
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 | |||
Appendix E. Change Log (to be removed by RFC Editor before | Appendix E. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 22 | publication) . . . . . . . . . . . . . . . . . . . . 23 | |||
E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22 | E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 | |||
E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 22 | E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
1. Introduction | 1. Introduction | |||
HTTP clients often encounter interrupted data transfers as a result | Hypertext Transfer Protocol (HTTP) clients often encounter | |||
of canceled requests or dropped connections. When a client has | interrupted data transfers as a result of canceled requests or | |||
stored a partial representation, it is desirable to request the | dropped connections. When a client has stored a partial | |||
remainder of that representation in a subsequent request rather than | representation, it is desirable to request the remainder of that | |||
transfer the entire representation. There are also a number of Web | representation in a subsequent request rather than transfer the | |||
applications that benefit from being able to request only a subset of | entire representation. Likewise, devices with limited local storage | |||
a larger representation, such as a single page of a very large | might benefit from being able to request only a subset of a larger | |||
document or only part of an image to be rendered by a device with | representation, such as a single page of a very large document, or | |||
limited local storage. | the dimensions of an embedded image. | |||
This document defines HTTP/1.1 range requests, partial responses, and | This document defines HTTP/1.1 range requests, partial responses, and | |||
the multipart/byteranges media type. The protocol for range requests | the multipart/byteranges media type, obsoleting those parts | |||
is an OPTIONAL feature of HTTP, designed so resources or recipients | previously defined in [RFC2616]. Range requests are an OPTIONAL | |||
that do not implement this feature can respond as if it is a normal | feature of HTTP, designed so that recipients not implementing this | |||
GET request without impacting interoperability. Partial responses | feature (or not supporting it for the target resource) can respond as | |||
are indicated by a distinct status code to not be mistaken for full | if it is a normal GET request without impacting interoperability. | |||
responses by intermediate caches that might not implement the | Partial responses are indicated by a distinct status code to not be | |||
mistaken for full responses by caches that might not implement the | ||||
feature. | feature. | |||
Although the HTTP range request mechanism is designed to allow for | Although the range request mechanism is designed to allow for | |||
extensible range types, this specification only defines requests for | extensible range types, this specification only defines requests for | |||
byte ranges. | byte ranges. | |||
1.1. Conformance and Error Handling | 1.1. Conformance and Error Handling | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
Conformance criteria and considerations regarding error handling are | Conformance criteria and considerations regarding error handling are | |||
skipping to change at page 4, line 49 | skipping to change at page 4, line 50 | |||
1.2. Syntax Notation | 1.2. Syntax Notation | |||
This specification uses the Augmented Backus-Naur Form (ABNF) | This specification uses the Augmented Backus-Naur Form (ABNF) | |||
notation of [RFC5234] with the list rule extension defined in Section | notation of [RFC5234] with the list rule extension defined in Section | |||
1.2 of [Part1]. Appendix C describes rules imported from other | 1.2 of [Part1]. Appendix C describes rules imported from other | |||
documents. Appendix D shows the collected ABNF with the list rule | documents. Appendix D shows the collected ABNF with the list rule | |||
expanded. | expanded. | |||
2. Range Units | 2. Range Units | |||
HTTP/1.1 allows a client to request that only part (a range) of the | A representation can be partitioned into subranges according to | |||
representation be included within the response. HTTP/1.1 uses range | various structural units, depending on the structure inherent in the | |||
units in the Range (Section 5.4) and Content-Range (Section 5.2) | representation's media type. This "range unit" is used in the | |||
header fields. A representation can be broken down into subranges | Accept-Ranges (Section 2.3) response header field to advertise | |||
according to various structural units. | support for range requests, the Range (Section 3.1) request header | |||
field to delineate the parts of a representation that are requested, | ||||
and the Content-Range (Section 4.2) payload header field to describe | ||||
which part of a representation is being transferred. | ||||
range-unit = bytes-unit / other-range-unit | range-unit = bytes-unit / other-range-unit | |||
bytes-unit = "bytes" | ||||
other-range-unit = token | ||||
HTTP/1.1 has been designed to allow implementations of applications | ||||
that do not depend on knowledge of ranges. The only range unit | ||||
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 | ||||
the whole Range header field (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. | ||||
2.1. Range Specifier Registry | ||||
The HTTP Range 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 require IETF Review (see | 2.1. Byte Ranges | |||
[RFC5226], Section 4.1). | ||||
The registry itself is maintained at | ||||
<http://www.iana.org/assignments/http-range-specifiers>. | ||||
3. Status Code Definitions | ||||
3.1. 206 Partial Content | ||||
The server has fulfilled the partial GET request for the resource. | Since representation data is transferred in payloads as a sequence of | |||
The request MUST have included a Range header field (Section 5.4) | octets, a byte range is a meaningful substructure for any | |||
indicating the desired range, and MAY have included an If-Range | representation transferable over HTTP (Section 3 of [Part2]). We | |||
header field (Section 5.3) to make the request conditional. | define the "bytes" range unit for expressing subranges of the data's | |||
octet sequence. | ||||
The response MUST include the following header fields: | bytes-unit = "bytes" | |||
o Either a Content-Range header field (Section 5.2) indicating the | A byte range operation MAY specify a single range of bytes, or a set | |||
range included with this response, or a multipart/byteranges | of ranges within a single representation. | |||
Content-Type including Content-Range fields for each part. If a | ||||
Content-Length header field is present in the response, its value | ||||
MUST match the actual number of octets transmitted in the message | ||||
body. | ||||
o Date | byte-ranges-specifier = bytes-unit "=" byte-range-set | |||
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | ||||
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | ||||
first-byte-pos = 1*DIGIT | ||||
last-byte-pos = 1*DIGIT | ||||
o Cache-Control, ETag, Expires, Content-Location and/or Vary, if the | The first-byte-pos value in a byte-range-spec gives the byte-offset | |||
header field would have been sent in a 200 (OK) response to the | of the first byte in a range. The last-byte-pos value gives the | |||
same request | byte-offset of the last byte in the range; that is, the byte | |||
positions specified are inclusive. Byte offsets start at zero. | ||||
If a 206 is sent in response to a request with an If-Range header | Examples of byte-ranges-specifier values: | |||
field, it SHOULD NOT include other representation header fields. | ||||
Otherwise, the response MUST include all of the representation header | ||||
fields that would have been returned with a 200 (OK) response to the | ||||
same request. | ||||
Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to | o The first 500 bytes (byte offsets 0-499, inclusive): | |||
determine freshness for 206 responses. | ||||
3.2. 416 Requested Range Not Satisfiable | bytes=0-499 | |||
A server SHOULD return a response with this status code if a request | o The second 500 bytes (byte offsets 500-999, inclusive): | |||
included a Range header field (Section 5.4), and none of the ranges- | ||||
specifier values in this field overlap the current extent of the | ||||
selected resource, and the request did not include an If-Range header | ||||
field (Section 5.3). (For byte-ranges, this means that the first- | ||||
byte-pos of all of the byte-range-spec values were greater than the | ||||
current length of the selected resource.) | ||||
When this status code is returned for a byte-range request, the | bytes=500-999 | |||
response SHOULD include a Content-Range header field specifying the | ||||
current length of the representation (see Section 5.2). This | ||||
response MUST NOT use the multipart/byteranges content-type. For | ||||
example, | ||||
HTTP/1.1 416 Requested Range Not Satisfiable | A byte-range-spec is invalid if the last-byte-pos value is present | |||
Date: Mon, 20 Jan 2012 15:41:54 GMT | and less than the first-byte-pos. | |||
Content-Range: bytes */47022 | ||||
Content-Type: image/gif | ||||
Note: Clients cannot depend on servers to send a 416 (Requested | A client can limit the number of bytes requested without knowing the | |||
Range Not Satisfiable) response instead of a 200 (OK) response for | size of the selected representation. If the last-byte-pos value is | |||
an unsatisfiable Range header field, since not all servers | absent, or if the value is greater than or equal to the current | |||
implement this header field. | length of the representation data, the byte range is interpreted as | |||
the remainder of the representation (i.e., the server replaces the | ||||
value of last-byte-pos with a value that is one less than the current | ||||
length of the selected representation). | ||||
4. Responses to a Range Request | A client can request the last N bytes of the selected representation | |||
using a suffix-byte-range-spec. | ||||
4.1. Response to a Single and Multiple Ranges Request | suffix-byte-range-spec = "-" suffix-length | |||
suffix-length = 1*DIGIT | ||||
When an HTTP message includes the content of a single range (for | If the selected representation is shorter than the specified suffix- | |||
example, a response to a request for a single range, or to a request | length, the entire representation is used. For example (assuming a | |||
for a set of ranges that overlap without any holes), this content is | representation of length 10000): | |||
transmitted with a Content-Range header field, and a Content-Length | ||||
header field showing the number of bytes actually transferred. For | ||||
example, | ||||
HTTP/1.1 206 Partial Content | o The final 500 bytes (byte offsets 9500-9999, inclusive): | |||
Date: Wed, 15 Nov 1995 06:25:24 GMT | ||||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | ||||
Content-Range: bytes 21010-47021/47022 | ||||
Content-Length: 26012 | ||||
Content-Type: image/gif | ||||
When an HTTP message includes the content of multiple ranges (for | bytes=-500 | |||
example, a response to a request for multiple non-overlapping | ||||
ranges), these are transmitted as a multipart message. The multipart | ||||
media type used for this purpose is "multipart/byteranges" as defined | ||||
in Appendix A. | ||||
A server MAY combine requested ranges when those ranges are | Or: | |||
overlapping (see Section 7.1). | ||||
A response to a request for a single range MUST NOT be sent using the | bytes=9500- | |||
multipart/byteranges media type. A response to a request for | ||||
multiple ranges, whose result is a single range, MAY be sent as a | ||||
multipart/byteranges media type with one part. A client that cannot | ||||
decode a multipart/byteranges message MUST NOT ask for multiple | ||||
ranges in a single request. | ||||
When a client asks for multiple ranges in one request, the server | o The first and last bytes only (bytes 0 and 9999): | |||
SHOULD return them in the order that they appeared in the request. | ||||
4.2. Combining Ranges | bytes=0-0,-1 | |||
A response might transfer only a subrange of a representation if the | o Other valid (but not canonical) specifications of the second 500 | |||
connection closed prematurely or if the request used one or more | bytes (byte offsets 500-999, inclusive): | |||
Range specifications. After several such transfers, a client might | ||||
have received several ranges of the same representation. These | ||||
ranges can only be safely combined if they all have in common the | ||||
same strong validator, where "strong validator" is defined to be | ||||
either an entity-tag that is not marked as weak (Section 2.3 of | ||||
[Part4]) or, if no entity-tag is provided, a Last-Modified value that | ||||
is strong in the sense defined by Section 2.2.2 of [Part4]. | ||||
When a client receives an incomplete 200 (OK) or 206 (Partial | bytes=500-600,601-999 | |||
Content) response and already has one or more stored responses for | bytes=500-700,601-999 | |||
the same method and effective request URI, all of the stored | ||||
responses with the same strong validator MAY be combined with the | ||||
partial content in this new response. If none of the stored | ||||
responses contain the same strong validator, then this new response | ||||
corresponds to a new representation and MUST NOT be combined with the | ||||
existing stored responses. | ||||
If the new response is an incomplete 200 (OK) response, then the | If a valid byte-range-set includes at least one byte-range-spec with | |||
header fields of that new response are used for any combined response | a first-byte-pos that is less than the current length of the | |||
and replace those of the matching stored responses. | representation, or at least one suffix-byte-range-spec with a non- | |||
zero suffix-length, then the byte-range-set is satisfiable. | ||||
Otherwise, the byte-range-set is unsatisfiable. | ||||
If the new response is a 206 (Partial Content) response and at least | In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- | |||
one of the matching stored responses is a 200 (OK), then the combined | length are expressed as decimal number of octets. Since there is no | |||
response header fields consist of the most recent 200 response's | predefined limit to the length of a payload, recipients ought to | |||
header fields. If all of the matching stored responses are 206 | anticipate potentially large decimal numerals and prevent parsing | |||
responses, then the stored response with the most header fields is | errors due to integer conversion overflows. | |||
used as the source of header fields for the combined response, except | ||||
that the client MUST use other header fields provided in the new | ||||
response, aside from Content-Range, to replace all instances of the | ||||
corresponding header fields in the stored response. | ||||
The combined response message body consists of the union of partial | 2.2. Other Range Units | |||
content ranges in the new response and each of the selected | ||||
responses. If the union consists of the entire range of the | ||||
representation, then the combined response MUST be recorded as a | ||||
complete 200 (OK) response with a Content-Length header field that | ||||
reflects the complete length. Otherwise, the combined response(s) | ||||
MUST include a Content-Range header field describing the included | ||||
range(s) and be recorded as incomplete. If the union consists of a | ||||
discontinuous range of the representation, then the client MAY store | ||||
it as either a multipart range response or as multiple 206 responses | ||||
with one continuous range each. | ||||
5. Header Field Definitions | Range units are intended to be extensible. New range units ought to | |||
be registered with IANA, as defined in Section 5.1. | ||||
This section defines the syntax and semantics of HTTP/1.1 header | other-range-unit = token | |||
fields related to range requests and partial responses. | ||||
5.1. Accept-Ranges | 2.3. Accept-Ranges | |||
The "Accept-Ranges" header field allows a resource to indicate its | The "Accept-Ranges" header field allows a server to indicate that it | |||
acceptance of range requests. | supports range requests for the target resource. | |||
Accept-Ranges = acceptable-ranges | Accept-Ranges = 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 support byte-range requests MAY send | |||
Accept-Ranges: bytes | Accept-Ranges: bytes | |||
but are not required to do so. Clients MAY generate range requests | but are not required to do so. Clients MAY generate range requests | |||
without having received this header field for the resource involved. | without having received this header field for the resource involved. | |||
Range units are defined in Section 2. | Range units are defined in Section 2. | |||
Servers that do not accept any kind of range request for a resource | Servers that do not support any kind of range request for the target | |||
MAY send | resource resource 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 | 3. Range Requests | |||
The "Content-Range" header field is sent with a partial | ||||
representation to specify where in the full representation the | ||||
payload body is intended to be applied. | ||||
Range units are defined in Section 2. | ||||
Content-Range = byte-content-range-spec | ||||
/ other-content-range-spec | ||||
byte-content-range-spec = bytes-unit SP | ||||
byte-range-resp-spec "/" | ||||
( instance-length / "*" ) | ||||
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | ||||
/ "*" | ||||
instance-length = 1*DIGIT | ||||
other-content-range-spec = other-range-unit SP | ||||
other-range-resp-spec | ||||
other-range-resp-spec = *CHAR | ||||
The header field SHOULD indicate the total length of the full | ||||
representation, unless this length is unknown or difficult to | ||||
determine. The asterisk "*" character means that the instance-length | ||||
is unknown at the time when the response was generated. | ||||
Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- | ||||
range-resp-spec MUST only specify one range, and MUST contain | ||||
absolute byte positions for both the first and last byte of the | ||||
range. | ||||
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 | ||||
instance-length value is less than or equal to its last-byte-pos | ||||
value, is invalid. The recipient of an invalid byte-content-range- | ||||
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 | ||||
status code 416 (Requested Range Not Satisfiable) SHOULD include a | ||||
Content-Range field with a byte-range-resp-spec of "*". The | ||||
instance-length specifies the current length of the selected | ||||
resource. A response with status code 206 (Partial Content) MUST NOT | ||||
include a Content-Range field with a byte-range-resp-spec of "*". | ||||
The "Content-Range" header field has no meaning for status codes that | 3.1. Range | |||
do not explicitly describe its semantic. Currently, only status | ||||
codes 206 (Partial Content) and 416 (Requested Range Not Satisfiable) | ||||
describe the meaning of this header field. | ||||
Examples of byte-content-range-spec values, assuming that the | The "Range" header field on a GET request modifies the method | |||
representation contains a total of 1234 bytes: | semantics to request transfer of only one or more subranges of the | |||
selected representation data, rather than the entire selected | ||||
representation data. | ||||
o The first 500 bytes: | Range = byte-ranges-specifier / other-ranges-specifier | |||
other-ranges-specifier = other-range-unit "=" other-range-set | ||||
other-range-set = 1*CHAR | ||||
bytes 0-499/1234 | A server MAY ignore the Range header field. However, origin servers | |||
and intermediate caches ought to support byte ranges when possible, | ||||
since Range supports efficient recovery from partially failed | ||||
transfers and partial retrieval of large representations. A server | ||||
MUST ignore a Range header field received with a request method other | ||||
than GET. | ||||
o The second 500 bytes: | An origin server MUST ignore a Range header field that contains a | |||
range unit it does not understand. A proxy MAY either discard a | ||||
Range header field that contains a range unit it does not understand | ||||
or pass it to the next inbound server when forwarding the request. | ||||
bytes 500-999/1234 | A server that supports range requests ought to ignore or reject a | |||
Range header field that consists of more than two overlapping ranges, | ||||
or a set of many small ranges that are not listed in ascending order, | ||||
since both are indications of either a broken client or a deliberate | ||||
denial of service attack (Section 6.1). A client SHOULD NOT request | ||||
multiple ranges that are inherently less efficient to process and | ||||
transfer than a single range that encompasses the same data. | ||||
o All except for the first 500 bytes: | A client that is requesting multiple ranges SHOULD list those ranges | |||
in ascending order (the order in which they would typically be | ||||
received in a complete representation) unless there is a specific | ||||
need to request a later part earlier. For example, a user agent | ||||
processing a large representation with an internal catalog of parts | ||||
might need to request later parts first, particularly if the | ||||
representation consists of pages stored in reverse order and the user | ||||
agent wishes to transfer one page at a time. | ||||
bytes 500-1233/1234 | The Range header field is evaluated after evaluating the | |||
preconditions of [Part4] and only if the result of their evaluation | ||||
is leading toward a 200 (OK) response. In other words, Range is | ||||
ignored when a conditional GET would result in a 304 (Not Modified) | ||||
response. | ||||
o The last 500 bytes: | The If-Range header field (Section 3.2) can be used as a precondition | |||
to applying the Range header field. | ||||
bytes 734-1233/1234 | If all of the preconditions are true, the server supports the Range | |||
header field for the target resource, and the specified range(s) are | ||||
valid and satisfiable (as defined in Section 2.1), the server SHOULD | ||||
send a 206 (Partial Content) response with a payload containing one | ||||
or more partial representations that correspond to the satisfiable | ||||
ranges requested, as defined in Section 4. | ||||
If the server ignores a byte-range-spec (for example if it is | If all of the preconditions are true, the server supports the Range | |||
syntactically invalid, or if it might be seen as a denial-of-service | header field for the target resource, and the specified range(s) are | |||
attack), the server SHOULD treat the request as if the invalid Range | invalid or unsatisfiable, the server SHOULD send a 416 (Range Not | |||
header field did not exist. (Normally, this means return a 200 (OK) | Satisfiable) response. | |||
response containing the full representation). | ||||
5.3. If-Range | 3.2. If-Range | |||
If a client has a partial copy of a representation and wishes to have | If a client has a partial copy of a representation and wishes to have | |||
an up-to-date copy of the entire representation, it could use the | an up-to-date copy of the entire representation, it could use the | |||
Range header field with a conditional GET (using either or both of | Range header field with a conditional GET (using either or both of | |||
If-Unmodified-Since and If-Match.) However, if the condition fails | If-Unmodified-Since and If-Match.) However, if the condition fails | |||
because the representation has been modified, the client would then | because the representation has been modified, the client would then | |||
have to make a second request to obtain the entire current | have to make a second request to obtain the entire current | |||
representation. | representation. | |||
The "If-Range" header field allows a client to "short-circuit" the | The "If-Range" header field allows a client to "short-circuit" the | |||
second request. Informally, its meaning is "if the representation is | second request. Informally, its meaning is: if the representation is | |||
unchanged, send me the part(s) that I am missing; otherwise, send me | unchanged, send me the part(s) that I am requesting in Range; | |||
the entire new representation". | otherwise, send me the entire representation. | |||
If-Range = entity-tag / HTTP-date | If-Range = entity-tag / HTTP-date | |||
Clients MUST NOT use an entity-tag marked as weak in an If-Range | Clients MUST NOT use an entity-tag marked as weak in an If-Range | |||
field value and MUST NOT use a Last-Modified date in an If-Range | field value and MUST NOT use a Last-Modified date in an If-Range | |||
field value unless it has no entity-tag for the representation and | field value unless it has no entity-tag for the representation and | |||
the Last-Modified date it does have for the representation is strong | the Last-Modified date it does have for the representation is strong | |||
in the sense defined by Section 2.2.2 of [Part4]. | in the sense defined by Section 2.2.2 of [Part4]. | |||
A server that evaluates a conditional range request that is | A server that evaluates a conditional range request that is | |||
applicable to one of its representations MUST evaluate the condition | applicable to one of its representations MUST evaluate the condition | |||
as false if the entity-tag used as a validator is marked as weak or, | as false if the entity-tag used as a validator is marked as weak or, | |||
when an HTTP-date is used as the validator, if the date value is not | when an HTTP-date is used as the validator, if the date value is not | |||
strong in the sense defined by Section 2.2.2 of [Part4]. (A server | strong in the sense defined by Section 2.2.2 of [Part4]. (A server | |||
can distinguish between a valid HTTP-date and any form of entity-tag | can distinguish between a valid HTTP-date and any form of entity-tag | |||
by examining the first two characters.) | by examining the first two characters.) | |||
The If-Range header field SHOULD only be sent by clients together | A client MUST NOT generate an If-Range header field in a request that | |||
with a Range header field. The If-Range header field MUST be ignored | does not contain a Range header field. A server MUST ignore an If- | |||
if it is received in a request that does not include a Range header | Range header field received in a request that does not contain a | |||
field. The If-Range header field MUST be ignored by a server that | Range header field. An origin server MUST ignore an If-Range header | |||
does not support the sub-range operation. | field received in a request for a target resource that does not | |||
support Range requests. | ||||
If the validator given in the If-Range header field matches the | If the validator given in the If-Range header field matches the | |||
current validator for the selected representation of the target | current validator for the selected representation of the target | |||
resource, then the server SHOULD send the specified sub-range of the | resource, then the server SHOULD process the Range header field as | |||
representation using a 206 (Partial Content) response. If the | requested. If the validator does not match, then the server MUST | |||
validator does not match, then the server SHOULD send the entire | ignore the Range header field. | |||
representation using a 200 (OK) response. | ||||
5.4. Range | 4. Responses to a Range Request | |||
4.1. 206 Partial Content | ||||
5.4.1. Byte Ranges | The 206 (Partial Content) status code indicates that the server is | |||
successfully fulfilling a range request for the target resource by | ||||
transferring one or more parts of the selected representation that | ||||
correspond to the satisfiable ranges found in the requests's Range | ||||
header field (Section 3.1). | ||||
Since all HTTP representations are transferred as sequences of bytes, | If a single part is being transferred, the server generating the 206 | |||
the concept of a byte range is meaningful for any HTTP | response MUST generate a Content-Range header field, describing what | |||
representation. (However, not all clients and servers need to | range of the selected representation is enclosed, and a payload | |||
support byte-range operations.) | consisting of the range. For example: | |||
Byte range specifications in HTTP apply to the sequence of bytes in | ||||
the representation data (not necessarily the same as the message | ||||
body). | ||||
A byte range operation MAY specify a single range of bytes, or a set | HTTP/1.1 206 Partial Content | |||
of ranges within a single representation. | Date: Wed, 15 Nov 1995 06:25:24 GMT | |||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | ||||
Content-Range: bytes 21010-47021/47022 | ||||
Content-Length: 26012 | ||||
Content-Type: image/gif | ||||
byte-ranges-specifier = bytes-unit "=" byte-range-set | ... 26012 bytes of partial image data ... | |||
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) | ||||
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | ||||
first-byte-pos = 1*DIGIT | ||||
last-byte-pos = 1*DIGIT | ||||
The first-byte-pos value in a byte-range-spec gives the byte-offset | If multiple parts are being transferred, the server generating the | |||
of the first byte in a range. The last-byte-pos value gives the | 206 response MUST generate a "multipart/byteranges" payload, as | |||
byte-offset of the last byte in the range; that is, the byte | defined in Appendix A, and a Content-Type header field containing the | |||
positions specified are inclusive. Byte offsets start at zero. | multipart/byteranges media type and its required boundary parameter. | |||
To avoid confusion with single part responses, a server MUST NOT | ||||
generate a Content-Range header field in the HTTP header block of a | ||||
multiple part response (this field will be sent in each part | ||||
instead). | ||||
If the last-byte-pos value is present, it MUST be greater than or | Within the header area of each body part in the multipart payload, | |||
equal to the first-byte-pos in that byte-range-spec, or the byte- | the server MUST generate a Content-Range header field corresponding | |||
range-spec is syntactically invalid. The recipient of a byte-range- | to the range being enclosed in that body part. If the selected | |||
set that includes one or more syntactically invalid byte-range-spec | representation would have had a Content-Type header field in a 200 | |||
values MUST ignore the header field that includes that byte-range- | (OK) response, the server SHOULD generate that same Content-Type | |||
set. | field in the header area of each body part. For example: | |||
If the last-byte-pos value is absent, or if the value is greater than | HTTP/1.1 206 Partial Content | |||
or equal to the current length of the representation data, last-byte- | Date: Wed, 15 Nov 1995 06:25:24 GMT | |||
pos is taken to be equal to one less than the current length of the | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |||
representation in bytes. | Content-Length: 1741 | |||
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | ||||
By its choice of last-byte-pos, a client can limit the number of | --THIS_STRING_SEPARATES | |||
bytes retrieved without knowing the size of the representation. | Content-Type: application/pdf | |||
Content-Range: bytes 500-999/8000 | ||||
suffix-byte-range-spec = "-" suffix-length | ...the first range... | |||
suffix-length = 1*DIGIT | --THIS_STRING_SEPARATES | |||
Content-Type: application/pdf | ||||
Content-Range: bytes 7000-7999/8000 | ||||
A suffix-byte-range-spec is used to specify the suffix of the | ...the second range | |||
representation data, of a length given by the suffix-length value. | --THIS_STRING_SEPARATES-- | |||
(That is, this form specifies the last N bytes of a representation.) | ||||
If the representation is shorter than the specified suffix-length, | ||||
the entire representation is used. | ||||
If a syntactically valid byte-range-set includes at least one byte- | When multiple ranges are requested, a server MAY coalesce any of the | |||
range-spec whose first-byte-pos is less than the current length of | ranges that overlap or that are separated by a gap that is smaller | |||
the representation, or at least one suffix-byte-range-spec with a | than the overhead of sending multiple parts, regardless of the order | |||
non-zero suffix-length, then the byte-range-set is satisfiable. | in which the corresponding byte-range-spec appeared in the received | |||
Otherwise, the byte-range-set is unsatisfiable. If the byte-range- | Range header field. Since the typical overhead between parts of a | |||
set is unsatisfiable, the server SHOULD return a response with a 416 | multipart/byteranges payload is around 80 bytes, depending on the | |||
(Requested Range Not Satisfiable) status code. Otherwise, the server | selected representation's media type and the chosen boundary | |||
SHOULD return a response with a 206 (Partial Content) status code | parameter length, it can be less efficient to transfer many small | |||
containing the satisfiable ranges of the representation. | disjoint parts than it is to transfer the entire selected | |||
representation. | ||||
In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- | A server MUST NOT generate a multipart response to a request for a | |||
length are expressed as decimal number of octets. Since there is no | single range, since a client that does not request multiple parts | |||
predefined limit to the length of an HTTP payload, recipients SHOULD | might not support multipart responses. However, a server MAY | |||
anticipate potentially large decimal numerals and prevent parsing | generate a multipart/byteranges payload with only a single body part | |||
errors due to integer conversion overflows. | if multiple ranges were requested and only one range was found to be | |||
satisfiable or only one range remained after coalescing. A client | ||||
that cannot process a multipart/byteranges response MUST NOT ask for | ||||
multiple ranges in a single request. | ||||
Examples of byte-ranges-specifier values (assuming a representation | When a multipart response payload is generated, the server SHOULD | |||
of length 10000): | send the parts in the same order that the corresponding byte-range- | |||
spec appeared in the received Range header field, excluding those | ||||
ranges that were deemed unsatisfiable or that were coalesced into | ||||
other ranges. A client that receives a multipart response MUST | ||||
inspect the Content-Range header field present in each body part in | ||||
order to determine which range is contained in that body part; a | ||||
client cannot rely on receiving the same ranges that it requested, | ||||
nor the same order that it requested. | ||||
o The first 500 bytes (byte offsets 0-499, inclusive): | When a 206 response is generated, the server MUST generate the | |||
following header fields, in addition to those required above, if the | ||||
field would have been sent in a 200 (OK) response to the same | ||||
request: Date, Cache-Control, ETag, Expires, Content-Location, and | ||||
Vary. | ||||
bytes=0-499 | If a 206 is generated in response to a request with an If-Range | |||
header field, the sender SHOULD NOT generate other representation | ||||
header fields beyond those required above, because the client is | ||||
understood to already have a prior response containing those header | ||||
fields. Otherwise, the sender MUST generate all of the | ||||
representation header fields that would have been sent in a 200 (OK) | ||||
response to the same request. | ||||
o The second 500 bytes (byte offsets 500-999, inclusive): | A 206 response is cacheable unless otherwise indicated by explicit | |||
cache controls (see Section 4.1.2 of [Part6]). | ||||
bytes=500-999 | 4.2. Content-Range | |||
o The final 500 bytes (byte offsets 9500-9999, inclusive): | The "Content-Range" header field is sent in a single part 206 | |||
(Partial Content) response to indicate the partial range of the | ||||
selected representation enclosed as the message payload, sent in each | ||||
part of a multipart 206 response to indicate the range enclosed | ||||
within each body part, and sent in 416 (Range Not Satisfiable) | ||||
responses to provide information about the selected representation. | ||||
bytes=-500 | Content-Range = byte-content-range | |||
/ other-content-range | ||||
Or: | byte-content-range = bytes-unit SP | |||
( byte-range-resp / unsatisfied-range ) | ||||
bytes=9500- | byte-range-resp = byte-range "/" ( complete-length / "*" ) | |||
byte-range = first-byte-pos "-" last-byte-pos | ||||
unsatisfied-range = "*/" complete-length | ||||
o The first and last bytes only (bytes 0 and 9999): | complete-length = 1*DIGIT | |||
bytes=0-0,-1 | other-content-range = other-range-unit SP other-range-resp | |||
other-range-resp = *CHAR | ||||
o Several legal but not canonical specifications of the second 500 | If a 206 (Partial Content) response contains a Content-Range header | |||
bytes (byte offsets 500-999, inclusive): | field with a range unit (Section 2) that the recipient does not | |||
understand, the recipient MUST NOT attempt to recombine it with a | ||||
stored representation. A proxy that receives such a message SHOULD | ||||
forward it downstream. | ||||
bytes=500-600,601-999 | For byte ranges, a sender SHOULD indicate the complete length of the | |||
bytes=500-700,601-999 | representation from which the range has been extracted, unless the | |||
complete length is unknown or difficult to determine. An asterisk | ||||
character ("*") in place of the complete-length indicates that the | ||||
representation length was unknown when the header field was | ||||
generated. | ||||
5.4.2. Range Retrieval Requests | The following example illustrates when the complete length of the | |||
selected representation is known by the sender to be 1234 bytes: | ||||
The "Range" header field defines the GET method (conditional or not) | Content-Range: bytes 42-1233/1234 | |||
to request one or more sub-ranges of the response representation | ||||
data, instead of the entire representation data. | ||||
Range = byte-ranges-specifier / other-ranges-specifier | and this second example illustrates when the complete length is | |||
other-ranges-specifier = other-range-unit "=" other-range-set | unknown: | |||
other-range-set = 1*CHAR | ||||
A server MAY ignore the Range header field. However, origin servers | Content-Range: bytes 42-1233/* | |||
and intermediate caches ought to support byte ranges when possible, | ||||
since Range supports efficient recovery from partially failed | ||||
transfers, and supports efficient partial retrieval of large | ||||
representations. | ||||
If the server supports the Range header field and the specified range | A Content-Range field value is invalid if it contains a byte-range- | |||
or ranges are appropriate for the representation: | resp that has a last-byte-pos value less than its first-byte-pos | |||
value, or a complete-length value less than or equal to its last- | ||||
byte-pos value. The recipient of an invalid Content-Range MUST NOT | ||||
attempt to recombine the received content with a stored | ||||
representation. | ||||
o The presence of a Range header field in an unconditional GET | A server generating a 416 (Range Not Satisfiable) response to a byte | |||
modifies what is returned if the GET is otherwise successful. In | range request SHOULD send a Content-Range header field with an | |||
other words, the response carries a status code of 206 (Partial | unsatisfied-range value, as in the following example: | |||
Content) instead of 200 (OK). | ||||
o The presence of a Range header field in a conditional GET (a | Content-Range: bytes */1234 | |||
request 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 returned if the GET is otherwise successful and the condition | ||||
is true. It does not affect the 304 (Not Modified) response | ||||
returned if the conditional is false. | ||||
In some cases, it might be more appropriate to use the If-Range | The complete-length in a 416 response indicates the current length of | |||
header field (see Section 5.3) in addition to the Range header field. | the selected representation. | |||
If a proxy that supports ranges receives a Range request, forwards | The "Content-Range" header field has no meaning for status codes that | |||
the request to an inbound server, and receives an entire | do not explicitly describe its semantic. For this specification, | |||
representation in reply, it MAY only return the requested range to | only the 206 (Partial Content) and 416 (Range Not Satisfiable) status | |||
its client. | codes describe a meaning for Content-Range. | |||
6. IANA Considerations | The following are examples of Content-Range values in which the | |||
selected representation contains a total of 1234 bytes: | ||||
6.1. Status Code Registration | o The first 500 bytes: | |||
Content-Range: bytes 0-499/1234 | ||||
o The second 500 bytes: | ||||
Content-Range: bytes 500-999/1234 | ||||
o All except for the first 500 bytes: | ||||
Content-Range: bytes 500-1233/1234 | ||||
o The last 500 bytes: | ||||
Content-Range: bytes 734-1233/1234 | ||||
4.3. Combining Ranges | ||||
A response might transfer only a subrange of a representation if the | ||||
connection closed prematurely or if the request used one or more | ||||
Range specifications. After several such transfers, a client might | ||||
have received several ranges of the same representation. These | ||||
ranges can only be safely combined if they all have in common the | ||||
same strong validator, where "strong validator" is defined to be | ||||
either an entity-tag that is not marked as weak (Section 2.3 of | ||||
[Part4]) or, if no entity-tag is provided, a Last-Modified value that | ||||
is strong in the sense defined by Section 2.2.2 of [Part4]. | ||||
A client that has received multiple partial responses to GET requests | ||||
on a target resource MAY combine those responses into a larger | ||||
continuous range if they share the same strong validator. | ||||
If the most recent response is an incomplete 200 (OK) response, then | ||||
the header fields of that response are used for any combined response | ||||
and replace those of the matching stored responses. | ||||
If the most recent response is a 206 (Partial Content) response and | ||||
at least one of the matching stored responses is a 200 (OK), then the | ||||
combined response header fields consist of the most recent 200 | ||||
response's header fields. If all of the matching stored responses | ||||
are 206 responses, then the stored response with the most recent | ||||
header fields is used as the source of header fields for the combined | ||||
response, except that the client MUST use other header fields | ||||
provided in the new response, aside from Content-Range, to replace | ||||
all instances of the corresponding header fields in the stored | ||||
response. | ||||
The combined response message body consists of the union of partial | ||||
content ranges in the new response and each of the selected | ||||
responses. If the union consists of the entire range of the | ||||
representation, then the client MUST record the combined response as | ||||
if it were a complete 200 (OK) response, including a Content-Length | ||||
header field that reflects the complete length. Otherwise, the | ||||
client MUST record the set of continuous ranges as one of the | ||||
following: an incomplete 200 (OK) response if the combined response | ||||
is a prefix of the representation, a single 206 (Partial Content) | ||||
response containing a multipart/byteranges body, or multiple 206 | ||||
(Partial Content) responses, each with one continuous range that is | ||||
indicated by a Content-Range header field. | ||||
4.4. 416 Range Not Satisfiable | ||||
The 416 (Range Not Satisfiable) status code indicates that none of | ||||
the ranges in the request's Range header field (Section 3.1) overlap | ||||
the current extent of the selected resource or that the set of ranges | ||||
requested has been rejected due to invalid ranges or an excessive | ||||
request of small or overlapping ranges. | ||||
For byte ranges, failing to overlap the current extent means that the | ||||
first-byte-pos of all of the byte-range-spec values were greater than | ||||
the current length of the selected representation. When this status | ||||
code is generated in response to a byte range request, the sender | ||||
SHOULD generate a Content-Range header field specifying the current | ||||
length of the selected representation (Section 4.2). | ||||
For example: | ||||
HTTP/1.1 416 Range Not Satisfiable | ||||
Date: Mon, 20 Jan 2012 15:41:54 GMT | ||||
Content-Range: bytes */47022 | ||||
Note: Because servers are free to ignore Range, many | ||||
implementations will simply respond with 200 (OK) if the requested | ||||
ranges are invalid or not satisfiable. That is partly because | ||||
most clients are prepared to receive a 200 (OK) to complete the | ||||
task (albeit less efficiently) and partly because clients might | ||||
not stop making an invalid partial request until they have | ||||
received a complete representation. Thus, clients cannot depend | ||||
on receiving a 416 (Range Not Satisfiable) response even when it | ||||
is most appropriate. | ||||
5. IANA Considerations | ||||
5.1. Range Unit Registry | ||||
The HTTP Range Unit Registry defines the name space for the range | ||||
unit names and refers to their corresponding specifications. The | ||||
registry is maintained at | ||||
<http://www.iana.org/assignments/http-parameters>. | ||||
5.1.1. Procedure | ||||
Registration of an HTTP Range Unit MUST include the following fields: | ||||
o Name | ||||
o Description | ||||
o Pointer to specification text | ||||
Values to be added to this name space require IETF Review (see | ||||
[RFC5226], Section 4.1). | ||||
5.1.2. Registrations | ||||
The initial HTTP Range Unit Registry shall contain the registrations | ||||
below: | ||||
+-------------+---------------------------------------+-------------+ | ||||
| Range Unit | Description | Reference | | ||||
| Name | | | | ||||
+-------------+---------------------------------------+-------------+ | ||||
| bytes | a range of octets | Section 2.1 | | ||||
| none | reserved as keyword, indicating no | Section 2.3 | | ||||
| | ranges are supported | | | ||||
+-------------+---------------------------------------+-------------+ | ||||
The change controller is: "IETF (iesg@ietf.org) - Internet | ||||
Engineering Task Force". | ||||
5.2. 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> shall 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 4.1 | | |||
| 416 | Requested Range Not Satisfiable | Section 3.2 | | | 416 | Range Not Satisfiable | Section 4.4 | | |||
+-------+---------------------------------+-------------+ | +-------+-----------------------+-------------+ | |||
6.2. Header Field Registration | 5.3. Header Field Registration | |||
The Message Header Field 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> shall 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 [BCP90]): | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Accept-Ranges | http | standard | Section 5.1 | | | Accept-Ranges | http | standard | Section 2.3 | | |||
| Content-Range | http | standard | Section 5.2 | | | Content-Range | http | standard | Section 4.2 | | |||
| If-Range | http | standard | Section 5.3 | | | If-Range | http | standard | Section 3.2 | | |||
| Range | http | standard | Section 5.4 | | | Range | http | standard | Section 3.1 | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
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 | 6. Security Considerations | |||
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 | Description | Reference | | ||||
| Specifier | | | | ||||
| Name | | | | ||||
+---------------+-------------------------------------+-------------+ | ||||
| bytes | a range of octets | Section 2 | | ||||
| none | reserved as keyword, indicating no | Section 5.1 | | ||||
| | ranges are supported | | | ||||
+---------------+-------------------------------------+-------------+ | ||||
The change controller is: "IETF (iesg@ietf.org) - Internet | ||||
Engineering Task Force". | ||||
7. Security Considerations | ||||
This section is meant to inform application developers, information | This section is meant to inform developers, information providers, | |||
providers, and users of the security limitations in HTTP/1.1 as | and users of known security concerns specific to the HTTP/1.1 range | |||
described by this document. The discussion does not include | request mechanisms. More general security considerations are | |||
definitive solutions to the problems revealed, though it does make | addressed in HTTP messaging [Part1] and semantics [Part2]. | |||
some suggestions for reducing security risks. | ||||
7.1. Overlapping Ranges | 6.1. Denial of Service Attacks using Range | |||
Range requests containing overlapping ranges can lead to the | Unconstrained multiple range requests are susceptible to denial of | |||
situation where a server is sending far more data than the size of | service attacks because the effort required to request many | |||
the complete resource representation. | overlapping ranges of the same data is tiny compared to the time, | |||
memory, and bandwidth consumed by attempting to serve the requested | ||||
data in many parts. Servers ought to ignore, coalesce, or reject | ||||
egregious range requests, such as requests for more than two | ||||
overlapping ranges or for many small ranges in a single set, | ||||
particularly when the ranges are requested out of order for no | ||||
apparent reason. Multipart range requests are not designed to | ||||
support random access. | ||||
8. Acknowledgments | 7. Acknowledgments | |||
See Section 9 of [Part1]. | See Section 9 of [Part1]. | |||
9. References | 8. References | |||
9.1. Normative References | 8.1. Normative References | |||
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
draft-ietf-httpbis-p1-messaging-21 (work in progress), | draft-ietf-httpbis-p1-messaging-22 (work in progress), | |||
October 2012. | February 2013. | |||
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Semantics and Content", | Protocol (HTTP/1.1): Semantics and Content", | |||
draft-ietf-httpbis-p2-semantics-21 (work in progress), | draft-ietf-httpbis-p2-semantics-22 (work in progress), | |||
October 2012. | February 2013. | |||
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Conditional Requests", | Protocol (HTTP/1.1): Conditional Requests", | |||
draft-ietf-httpbis-p4-conditional-21 (work in progress), | draft-ietf-httpbis-p4-conditional-22 (work in progress), | |||
October 2012. | February 2013. | |||
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | |||
draft-ietf-httpbis-p6-cache-21 (work in progress), | draft-ietf-httpbis-p6-cache-22 (work in progress), | |||
October 2012. | February 2013. | |||
[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. | |||
9.2. Informative References | 8.2. Informative References | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Specifications and Registration Procedures", BCP 13, | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | RFC 6838, January 2013. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
September 2004. | September 2004. | |||
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Registration Procedures", BCP 13, RFC 4288, December 2005. | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | ||||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | 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 a 206 (Partial Content) response message includes the content of | |||
content of multiple ranges (a response to a request for multiple non- | multiple ranges, they are transmitted as body parts in a multipart | |||
overlapping ranges), these are transmitted as a multipart message | message body ([RFC2046], Section 5.1) with the media type of | |||
body ([RFC2046], Section 5.1). The media type for this purpose is | "multipart/byteranges". The following definition is to be registered | |||
called "multipart/byteranges". The following is to be registered | with IANA [BCP13]. | |||
with IANA [RFC4288]. | ||||
The multipart/byteranges media type includes one or more parts, each | The multipart/byteranges media type includes one or more body parts, | |||
with its own Content-Type and Content-Range fields. The required | each with its own Content-Type and Content-Range fields. The | |||
boundary parameter specifies the boundary string used to separate | required boundary parameter specifies the boundary string used to | |||
each body-part. | separate each body part. | |||
Type name: multipart | Type name: multipart | |||
Subtype name: byteranges | Subtype name: byteranges | |||
Required parameters: boundary | Required parameters: boundary | |||
Optional parameters: none | Optional parameters: none | |||
Encoding considerations: only "7bit", "8bit", or "binary" are | Encoding considerations: only "7bit", "8bit", or "binary" are | |||
skipping to change at page 18, line 22 | skipping to change at page 19, line 47 | |||
Person and email address to contact for further information: See | Person and email address to contact for further information: See | |||
Authors Section. | Authors Section. | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Restrictions on usage: none | Restrictions on usage: none | |||
Author/Change controller: IESG | Author/Change controller: IESG | |||
Note: Despite the name "multipart/byteranges" is not limited to | Implementation Notes: | |||
the byte ranges only. | ||||
For example: | ||||
HTTP/1.1 206 Partial Content | ||||
Date: Wed, 15 Nov 1995 06:25:24 GMT | ||||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | ||||
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | ||||
--THIS_STRING_SEPARATES | 1. Additional CRLFs might precede the first boundary string in the | |||
Content-type: application/pdf | body. | |||
Content-range: bytes 500-999/8000 | ||||
...the first range... | 2. Although [RFC2046] permits the boundary string to be quoted, some | |||
--THIS_STRING_SEPARATES | existing implementations handle a quoted boundary string | |||
Content-type: application/pdf | incorrectly. | |||
Content-range: bytes 7000-7999/8000 | ||||
...the second range | 3. A number of clients and servers were coded to an early draft of | |||
--THIS_STRING_SEPARATES-- | the byteranges specification that used a media type of multipart/ | |||
x-byteranges, which is almost (but not quite) compatible with | ||||
this type. | ||||
Another example, using the "exampleunit" range unit: | Despite the name, the "multipart/byteranges" media type is not | |||
limited to byte ranges. The following example uses an "exampleunit" | ||||
range unit: | ||||
HTTP/1.1 206 Partial Content | HTTP/1.1 206 Partial Content | |||
Date: Tue, 14 Nov 1995 06:25:24 GMT | Date: Tue, 14 Nov 1995 06:25:24 GMT | |||
Last-Modified: Tue, 14 July 04:58:08 GMT | Last-Modified: Tue, 14 July 04:58:08 GMT | |||
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | Content-Length: 2331785 | |||
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | ||||
--THIS_STRING_SEPARATES | --THIS_STRING_SEPARATES | |||
Content-type: video/example | Content-Type: video/example | |||
Content-range: exampleunit 1.2-4.3/25 | Content-Range: exampleunit 1.2-4.3/25 | |||
...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: | Appendix B. Changes from RFC 2616 | |||
1. Additional CRLFs MAY precede the first boundary string in the | ||||
body. | ||||
2. Although [RFC2046] permits the boundary string to be quoted, some | ||||
existing implementations handle a quoted boundary string | ||||
incorrectly. | ||||
3. A number of clients and servers were coded to an early draft of | A weak validator cannot be used in a 206 response. (Section 4.1) | |||
the byteranges specification to use a media type of multipart/ | ||||
x-byteranges, which is almost, but not quite compatible with the | ||||
version documented in HTTP/1.1. | ||||
Appendix B. Changes from RFC 2616 | The Content-Range header field only has meaning when the status code | |||
explicitly defines its use. (Section 4.2) | ||||
Introduce Range Specifier Registry. (Section 2.1) | Servers are given more leeway in how they respond to a range request, | |||
in order to mitigate abuse by malicious (or just greedy) clients. | ||||
Clarify that it is not ok to use a weak validator in a 206 response. | multipart/byteranges can consist of a single part. (Appendix A) | |||
(Section 3.1) | ||||
Clarify that multipart/byteranges can consist of a single part. | This specification introduces a Range Unit Registry. (Section 5.1) | |||
(Appendix A) | ||||
Appendix C. Imported ABNF | Appendix C. Imported ABNF | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | |||
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | |||
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any | |||
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII | |||
character). | character). | |||
Note that all rules derived from token are to be compared case- | Note that all rules derived from token are to be compared case- | |||
insensitively, like range-unit and acceptable-ranges. | insensitively, like range-unit and acceptable-ranges. | |||
The rules below are defined in [Part1]: | The rules below are defined in [Part1]: | |||
OWS = <OWS, defined in [Part1], Section 3.2.1> | OWS = <OWS, defined in [Part1], Section 3.2.3> | |||
token = <token, defined in [Part1], Section 3.2.4> | token = <token, defined in [Part1], Section 3.2.6> | |||
The rules below are defined in other parts: | The rules below are defined in other parts: | |||
HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> | HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1> | |||
entity-tag = <entity-tag, defined in [Part4], Section 2.3> | entity-tag = <entity-tag, defined in [Part4], Section 2.3> | |||
Appendix D. Collected ABNF | Appendix D. Collected ABNF | |||
Accept-Ranges = acceptable-ranges | Accept-Ranges = acceptable-ranges | |||
Content-Range = byte-content-range-spec / other-content-range-spec | Content-Range = byte-content-range / other-content-range | |||
HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1> | HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1> | |||
If-Range = entity-tag / HTTP-date | If-Range = entity-tag / HTTP-date | |||
OWS = <OWS, defined in [Part1], Section 3.2.1> | OWS = <OWS, defined in [Part1], Section 3.2.3> | |||
Range = byte-ranges-specifier / other-ranges-specifier | Range = byte-ranges-specifier / other-ranges-specifier | |||
acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS | acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS | |||
range-unit ] ) ) / "none" | range-unit ] ) ) / "none" | |||
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( | byte-content-range = bytes-unit SP ( byte-range-resp / | |||
instance-length / "*" ) | unsatisfied-range ) | |||
byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" | byte-range = first-byte-pos "-" last-byte-pos | |||
byte-range-resp = byte-range "/" ( complete-length / "*" ) | ||||
byte-range-set = *( "," OWS ) ( byte-range-spec / | byte-range-set = *( "," OWS ) ( byte-range-spec / | |||
suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / | suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / | |||
suffix-byte-range-spec ) ] ) | suffix-byte-range-spec ) ] ) | |||
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | byte-range-spec = first-byte-pos "-" [ last-byte-pos ] | |||
byte-ranges-specifier = bytes-unit "=" byte-range-set | byte-ranges-specifier = bytes-unit "=" byte-range-set | |||
bytes-unit = "bytes" | bytes-unit = "bytes" | |||
complete-length = 1*DIGIT | ||||
entity-tag = <entity-tag, defined in [Part4], Section 2.3> | entity-tag = <entity-tag, defined in [Part4], Section 2.3> | |||
first-byte-pos = 1*DIGIT | first-byte-pos = 1*DIGIT | |||
instance-length = 1*DIGIT | ||||
last-byte-pos = 1*DIGIT | last-byte-pos = 1*DIGIT | |||
other-content-range-spec = other-range-unit SP other-range-resp-spec | other-content-range = other-range-unit SP other-range-resp | |||
other-range-resp-spec = *CHAR | other-range-resp = *CHAR | |||
other-range-set = 1*CHAR | other-range-set = 1*CHAR | |||
other-range-unit = token | other-range-unit = token | |||
other-ranges-specifier = other-range-unit "=" other-range-set | other-ranges-specifier = other-range-unit "=" other-range-set | |||
range-unit = bytes-unit / other-range-unit | range-unit = bytes-unit / other-range-unit | |||
suffix-byte-range-spec = "-" suffix-length | suffix-byte-range-spec = "-" suffix-length | |||
suffix-length = 1*DIGIT | suffix-length = 1*DIGIT | |||
token = <token, defined in [Part1], Section 3.2.4> | token = <token, defined in [Part1], Section 3.2.6> | |||
unsatisfied-range = "*/" complete-length | ||||
Appendix E. Change Log (to be removed by RFC Editor before publication) | Appendix E. Change Log (to be removed by RFC Editor before publication) | |||
Changes up to the first Working Group Last Call draft are summarized | Changes up to the first Working Group Last Call draft are summarized | |||
in <http://tools.ietf.org/html/ | in <http://tools.ietf.org/html/ | |||
draft-ietf-httpbis-p5-range-19#appendix-D>. | draft-ietf-httpbis-p5-range-19#appendix-D>. | |||
E.1. Since draft-ietf-httpbis-p5-range-19 | E.1. Since draft-ietf-httpbis-p5-range-19 | |||
Closed issues: | Closed issues: | |||
skipping to change at page 22, line 35 | skipping to change at page 23, line 35 | |||
introduction of new IANA registries as normative changes" | introduction of new IANA registries as normative changes" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units | o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units | |||
vs leading zeroes vs size" | vs leading zeroes vs size" | |||
E.2. Since draft-ietf-httpbis-p5-range-20 | E.2. Since draft-ietf-httpbis-p5-range-20 | |||
o Conformance criteria and considerations regarding error handling | o Conformance criteria and considerations regarding error handling | |||
are now defined in Part 1. | are now defined in Part 1. | |||
E.3. Since draft-ietf-httpbis-p5-range-21 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security | ||||
consideration: range flooding" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing | ||||
heuristic caching for new status codes" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add | ||||
limitations to Range to reduce its use as a denial-of-service | ||||
tool" | ||||
Index | Index | |||
2 | 2 | |||
206 Partial Content (status code) 5 | 206 Partial Content (status code) 10 | |||
4 | 4 | |||
416 Requested Range Not Satisfiable (status code) 6 | 416 Range Not Satisfiable (status code) 15 | |||
A | A | |||
Accept-Ranges header field 8 | Accept-Ranges header field 7 | |||
C | C | |||
Content-Range header field 9 | Content-Range header field 12 | |||
G | G | |||
Grammar | Grammar | |||
Accept-Ranges 8 | Accept-Ranges 7 | |||
acceptable-ranges 8 | acceptable-ranges 7 | |||
byte-content-range-spec 9 | byte-content-range 12 | |||
byte-range-resp-spec 9 | byte-range 12 | |||
byte-range-set 12 | byte-range-resp 12 | |||
byte-range-spec 12 | byte-range-set 5 | |||
byte-ranges-specifier 12 | byte-range-spec 5 | |||
byte-ranges-specifier 5 | ||||
bytes-unit 5 | bytes-unit 5 | |||
Content-Range 9 | complete-length 12 | |||
first-byte-pos 12 | Content-Range 12 | |||
If-Range 11 | first-byte-pos 5 | |||
instance-length 9 | If-Range 9 | |||
last-byte-pos 12 | last-byte-pos 5 | |||
other-range-unit 5 | other-content-range 12 | |||
Range 13 | other-range-resp 12 | |||
other-range-unit 5, 7 | ||||
Range 7 | ||||
range-unit 5 | range-unit 5 | |||
ranges-specifier 12 | ranges-specifier 5 | |||
suffix-byte-range-spec 12 | suffix-byte-range-spec 6 | |||
suffix-length 12 | suffix-length 6 | |||
unsatisfied-range 12 | ||||
I | I | |||
If-Range header field 10 | If-Range header field 9 | |||
M | M | |||
Media Type | Media Type | |||
multipart/byteranges 17 | multipart/byteranges 18 | |||
multipart/x-byteranges 19 | multipart/x-byteranges 20 | |||
multipart/byteranges Media Type 17 | multipart/byteranges Media Type 18 | |||
multipart/x-byteranges Media Type 19 | multipart/x-byteranges Media Type 20 | |||
R | R | |||
Range header field 11 | Range header field 7 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe Systems Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
San Jose, CA 95110 | San Jose, CA 95110 | |||
USA | USA | |||
EMail: fielding@gbiv.com | EMail: fielding@gbiv.com | |||
End of changes. 156 change blocks. | ||||
549 lines changed or deleted | 610 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |