draft-ietf-httpbis-p5-range-22.txt   draft-ietf-httpbis-p5-range-23.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: August 27, 2013 J. Reschke, Ed. Expires: January 16, 2014 J. Reschke, Ed.
greenbytes greenbytes
February 23, 2013 July 15, 2013
Hypertext Transfer Protocol (HTTP/1.1): Range Requests Hypertext Transfer Protocol (HTTP/1.1): Range Requests
draft-ietf-httpbis-p5-range-22 draft-ietf-httpbis-p5-range-23
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.3. The changes in this draft are summarized in Appendix E.4.
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 August 27, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7
2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10
4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10
4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15
5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16
5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 43 skipping to change at page 3, line 43
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
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) . . . . . . . . . . . . . . . . . . . . 23 publication) . . . . . . . . . . . . . . . . . . . . 23
E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23 E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 23
E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23
E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23 E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Hypertext Transfer Protocol (HTTP) clients often encounter Hypertext Transfer Protocol (HTTP) clients often encounter
interrupted data transfers as a result of canceled requests or interrupted data transfers as a result of canceled requests or
dropped connections. When a client has stored a partial dropped connections. When a client has stored a partial
representation, it is desirable to request the remainder of that representation, it is desirable to request the remainder of that
representation in a subsequent request rather than transfer the representation in a subsequent request rather than transfer the
entire representation. Likewise, devices with limited local storage entire representation. Likewise, devices with limited local storage
might benefit from being able to request only a subset of a larger might benefit from being able to request only a subset of a larger
representation, such as a single page of a very large document, or representation, such as a single page of a very large document, or
the dimensions of an embedded image. 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, obsoleting those parts the multipart/byteranges media type. Range requests are an OPTIONAL
previously defined in [RFC2616]. Range requests are an OPTIONAL
feature of HTTP, designed so that recipients not implementing this feature of HTTP, designed so that recipients not implementing this
feature (or not supporting it for the target resource) can respond as feature (or not supporting it for the target resource) can respond as
if it is a normal GET request without impacting interoperability. if it is a normal GET request without impacting interoperability.
Partial responses are indicated by a distinct status code to not be Partial responses are indicated by a distinct status code to not be
mistaken for full responses by caches that might not implement the mistaken for full responses by caches that might not implement the
feature. feature.
Although the 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.
skipping to change at page 5, line 22 skipping to change at page 5, line 21
2.1. Byte Ranges 2.1. Byte Ranges
Since representation data is transferred in payloads as a sequence of Since representation data is transferred in payloads as a sequence of
octets, a byte range is a meaningful substructure for any octets, a byte range is a meaningful substructure for any
representation transferable over HTTP (Section 3 of [Part2]). We representation transferable over HTTP (Section 3 of [Part2]). We
define the "bytes" range unit for expressing subranges of the data's define the "bytes" range unit for expressing subranges of the data's
octet sequence. octet sequence.
bytes-unit = "bytes" bytes-unit = "bytes"
A byte range operation MAY specify a single range of bytes, or a set A byte range request can specify a single range of bytes, or a set of
of ranges within a single representation. 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
skipping to change at page 6, line 16 skipping to change at page 6, line 15
value of last-byte-pos with a value that is one less than the current value of last-byte-pos with a value that is one less than the current
length of the selected representation). length of the selected representation).
A client can request the last N bytes of the selected representation A client can request the last N bytes of the selected representation
using a suffix-byte-range-spec. using a suffix-byte-range-spec.
suffix-byte-range-spec = "-" suffix-length suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
If the selected representation is shorter than the specified suffix- If the selected representation is shorter than the specified suffix-
length, the entire representation is used. For example (assuming a length, the entire representation is used.
representation of length 10000):
Additional examples, assuming a representation of length 10000:
o The final 500 bytes (byte offsets 9500-9999, inclusive): o The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500 bytes=-500
Or: Or:
bytes=9500- bytes=9500-
o The first and last bytes only (bytes 0 and 9999): o The first and last bytes only (bytes 0 and 9999):
skipping to change at page 8, line 28 skipping to change at page 8, line 28
A client that is requesting multiple ranges SHOULD list those ranges A client that is requesting multiple ranges SHOULD list those ranges
in ascending order (the order in which they would typically be in ascending order (the order in which they would typically be
received in a complete representation) unless there is a specific received in a complete representation) unless there is a specific
need to request a later part earlier. For example, a user agent need to request a later part earlier. For example, a user agent
processing a large representation with an internal catalog of parts processing a large representation with an internal catalog of parts
might need to request later parts first, particularly if the might need to request later parts first, particularly if the
representation consists of pages stored in reverse order and the user representation consists of pages stored in reverse order and the user
agent wishes to transfer one page at a time. agent wishes to transfer one page at a time.
The Range header field is evaluated after evaluating the The Range header field is evaluated after evaluating the precondition
preconditions of [Part4] and only if the result of their evaluation header fields defined in [Part4], and only if the result in absence
is leading toward a 200 (OK) response. In other words, Range is of the Range header field would be a 200 (OK) response. In other
ignored when a conditional GET would result in a 304 (Not Modified) words, Range is ignored when a conditional GET would result in a 304
response. (Not Modified) response.
The If-Range header field (Section 3.2) can be used as a precondition The If-Range header field (Section 3.2) can be used as a precondition
to applying the Range header field. to applying the Range header field.
If all of the preconditions are true, the server supports the Range If all of the preconditions are true, the server supports the Range
header field for the target resource, and the specified range(s) are header field for the target resource, and the specified range(s) are
valid and satisfiable (as defined in Section 2.1), the server SHOULD valid and satisfiable (as defined in Section 2.1), the server SHOULD
send a 206 (Partial Content) response with a payload containing one send a 206 (Partial Content) response with a payload containing one
or more partial representations that correspond to the satisfiable or more partial representations that correspond to the satisfiable
ranges requested, as defined in Section 4. ranges requested, as defined in Section 4.
skipping to change at page 9, line 22 skipping to change at page 9, line 22
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 requesting in Range; unchanged, send me the part(s) that I am requesting in Range;
otherwise, send me the entire 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 A client MUST NOT generate an If-Range header field containing an
field value and MUST NOT use a Last-Modified date in an If-Range entity-tag that is marked as weak. A client MUST NOT generate an If-
field value unless it has no entity-tag for the representation and Range header field containing a Last-Modified date unless the client
the Last-Modified date it does have for the representation is strong has no entity-tag for the corresponding representation and the Last-
in the sense defined by Section 2.2.2 of [Part4]. Modified date is strong 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.)
A client MUST NOT generate an If-Range header field in a request that A client MUST NOT generate an If-Range header field in a request that
skipping to change at page 10, line 4 skipping to change at page 10, line 6
field received in a request for a target resource that does not field received in a request for a target resource that does not
support Range requests. support Range requests.
If the validator given in the If-Range header field matches the If the validator given in the If-Range header field matches the
current validator for the selected representation of the target current validator for the selected representation of the target
resource, then the server SHOULD process the Range header field as resource, then the server SHOULD process the Range header field as
requested. If the validator does not match, then the server MUST requested. If the validator does not match, then the server MUST
ignore the Range header field. ignore the Range header field.
4. Responses to a Range Request 4. Responses to a Range Request
4.1. 206 Partial Content 4.1. 206 Partial Content
The 206 (Partial Content) status code indicates that the server is The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that transferring one or more parts of the selected representation that
correspond to the satisfiable ranges found in the requests's Range correspond to the satisfiable ranges found in the request's Range
header field (Section 3.1). header field (Section 3.1).
If a single part is being transferred, the server generating the 206 If a single part is being transferred, the server generating the 206
response MUST generate a Content-Range header field, describing what response MUST generate a Content-Range header field, describing what
range of the selected representation is enclosed, and a payload range of the selected representation is enclosed, and a payload
consisting of the range. For example: consisting of the range. For example:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
skipping to change at page 11, line 40 skipping to change at page 11, line 40
parameter length, it can be less efficient to transfer many small parameter length, it can be less efficient to transfer many small
disjoint parts than it is to transfer the entire selected disjoint parts than it is to transfer the entire selected
representation. representation.
A server MUST NOT generate a multipart response to a request for a A server MUST NOT generate a multipart response to a request for a
single range, since a client that does not request multiple parts single range, since a client that does not request multiple parts
might not support multipart responses. However, a server MAY might not support multipart responses. However, a server MAY
generate a multipart/byteranges payload with only a single body part generate a multipart/byteranges payload with only a single body part
if multiple ranges were requested and only one range was found to be if multiple ranges were requested and only one range was found to be
satisfiable or only one range remained after coalescing. A client satisfiable or only one range remained after coalescing. A client
that cannot process a multipart/byteranges response MUST NOT ask for that cannot process a multipart/byteranges response MUST NOT generate
multiple ranges in a single request. a request that asks for multiple ranges.
When a multipart response payload is generated, the server SHOULD When a multipart response payload is generated, the server SHOULD
send the parts in the same order that the corresponding byte-range- send the parts in the same order that the corresponding byte-range-
spec appeared in the received Range header field, excluding those spec appeared in the received Range header field, excluding those
ranges that were deemed unsatisfiable or that were coalesced into ranges that were deemed unsatisfiable or that were coalesced into
other ranges. A client that receives a multipart response MUST other ranges. A client that receives a multipart response MUST
inspect the Content-Range header field present in each body part in inspect the Content-Range header field present in each body part in
order to determine which range is contained in that body part; a order to determine which range is contained in that body part; a
client cannot rely on receiving the same ranges that it requested, client cannot rely on receiving the same ranges that it requested,
nor the same order that it requested. nor the same order that it requested.
skipping to change at page 14, line 47 skipping to change at page 14, line 47
are 206 responses, then the stored response with the most recent are 206 responses, then the stored response with the most recent
header fields is used as the source of header fields for the combined header fields is used as the source of header fields for the combined
response, except that the client MUST use other header fields response, except that the client MUST use other header fields
provided in the new response, aside from Content-Range, to replace provided in the new response, aside from Content-Range, to replace
all instances of the corresponding header fields in the stored all instances of the corresponding header fields in the stored
response. response.
The combined response message body consists of the union of partial The combined response message body consists of the union of partial
content ranges in the new response and each of the selected content ranges in the new response and each of the selected
responses. If the union consists of the entire range of the responses. If the union consists of the entire range of the
representation, then the client MUST record the combined response as representation, then the client MUST process the combined response as
if it were a complete 200 (OK) response, including a Content-Length if it were a complete 200 (OK) response, including a Content-Length
header field that reflects the complete length. Otherwise, the header field that reflects the complete length. Otherwise, the
client MUST record the set of continuous ranges as one of the client MUST process the set of continuous ranges as one of the
following: an incomplete 200 (OK) response if the combined response following: an incomplete 200 (OK) response if the combined response
is a prefix of the representation, a single 206 (Partial Content) is a prefix of the representation, a single 206 (Partial Content)
response containing a multipart/byteranges body, or multiple 206 response containing a multipart/byteranges body, or multiple 206
(Partial Content) responses, each with one continuous range that is (Partial Content) responses, each with one continuous range that is
indicated by a Content-Range header field. indicated by a Content-Range header field.
4.4. 416 Range Not Satisfiable 4.4. 416 Range Not Satisfiable
The 416 (Range Not Satisfiable) status code indicates that none of 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 ranges in the request's Range header field (Section 3.1) overlap
skipping to change at page 15, line 26 skipping to change at page 15, line 26
For byte ranges, failing to overlap the current extent means that the 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 first-byte-pos of all of the byte-range-spec values were greater than
the current length of the selected representation. When this status the current length of the selected representation. When this status
code is generated in response to a byte range request, the sender code is generated in response to a byte range request, the sender
SHOULD generate a Content-Range header field specifying the current SHOULD generate a Content-Range header field specifying the current
length of the selected representation (Section 4.2). length of the selected representation (Section 4.2).
For example: For example:
HTTP/1.1 416 Range Not Satisfiable HTTP/1.1 416 Range Not Satisfiable
Date: Mon, 20 Jan 2012 15:41:54 GMT Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022 Content-Range: bytes */47022
Note: Because servers are free to ignore Range, many Note: Because servers are free to ignore Range, many
implementations will simply respond with 200 (OK) if the requested implementations will simply respond with the entire selected
ranges are invalid or not satisfiable. That is partly because representation in a 200 (OK) response. That is partly because
most clients are prepared to receive a 200 (OK) to complete the most clients are prepared to receive a 200 (OK) to complete the
task (albeit less efficiently) and partly because clients might task (albeit less efficiently) and partly because clients might
not stop making an invalid partial request until they have not stop making an invalid partial request until they have
received a complete representation. Thus, clients cannot depend received a complete representation. Thus, clients cannot depend
on receiving a 416 (Range Not Satisfiable) response even when it on receiving a 416 (Range Not Satisfiable) response even when it
is most appropriate. is most appropriate.
5. IANA Considerations 5. IANA Considerations
5.1. Range Unit Registry 5.1. Range Unit Registry
The HTTP Range Unit Registry defines the name space for the range The HTTP Range Unit Registry defines the name space for the range
unit names and refers to their corresponding specifications. The unit names and refers to their corresponding specifications. The
registry is maintained at registry will be created and maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
5.1.1. Procedure 5.1.1. Procedure
Registration of an HTTP Range Unit MUST include the following fields: Registration of an HTTP Range Unit MUST include the following fields:
o Name o Name
o Description o Description
skipping to change at page 16, line 46 skipping to change at page 16, line 46
+-------+-----------------------+-------------+ +-------+-----------------------+-------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------+-------------+ +-------+-----------------------+-------------+
| 206 | Partial Content | Section 4.1 | | 206 | Partial Content | Section 4.1 |
| 416 | Range Not Satisfiable | Section 4.4 | | 416 | Range Not Satisfiable | Section 4.4 |
+-------+-----------------------+-------------+ +-------+-----------------------+-------------+
5.3. Header Field Registration 5.3. Header Field Registration
The Message Header Field Registry located at <http://www.iana.org/ HTTP header fields are registered within the Message Header Field
assignments/message-headers/message-header-index.html> shall be Registry maintained at <http://www.iana.org/assignments/
updated with the permanent registrations below (see [BCP90]): message-headers/message-header-index.html>.
This document defines the following HTTP header fields, so their
associated registry entries shall be updated according to the
permanent registrations below (see [BCP90]):
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Accept-Ranges | http | standard | Section 2.3 | | Accept-Ranges | http | standard | Section 2.3 |
| Content-Range | http | standard | Section 4.2 | | Content-Range | http | standard | Section 4.2 |
| If-Range | http | standard | Section 3.2 | | If-Range | http | standard | Section 3.2 |
| Range | http | standard | Section 3.1 | | Range | http | standard | Section 3.1 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
skipping to change at page 17, line 47 skipping to change at page 17, line 47
7. Acknowledgments 7. Acknowledgments
See Section 9 of [Part1]. See Section 9 of [Part1].
8. References 8. References
8.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-22 (work in progress), draft-ietf-httpbis-p1-messaging-23 (work in progress),
February 2013. July 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-22 (work in progress), draft-ietf-httpbis-p2-semantics-23 (work in progress),
February 2013. July 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-22 (work in progress), draft-ietf-httpbis-p4-conditional-23 (work in progress),
February 2013. July 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-22 (work in progress), draft-ietf-httpbis-p6-cache-23 (work in progress),
February 2013. July 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.
skipping to change at page 19, line 45 skipping to change at page 19, line 45
Macintosh file type code(s): none Macintosh file type code(s): none
Person and email address to contact for further information: See Person and email address to contact for further information: See
Authors Section. Authors Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IESG Author: See Authors Section.
Change controller: IESG
Implementation Notes: Implementation Notes:
1. Additional CRLFs might precede the first boundary string in the 1. Additional CRLFs might precede the first boundary string in the
body. body.
2. Although [RFC2046] permits the boundary string to be quoted, some 2. Although [RFC2046] permits the boundary string to be quoted, some
existing implementations handle a quoted boundary string existing implementations handle a quoted boundary string
incorrectly. incorrectly.
skipping to change at page 22, line 4 skipping to change at page 21, line 28
OWS = <OWS, defined in [Part1], Section 3.2.3> OWS = <OWS, defined in [Part1], Section 3.2.3>
token = <token, defined in [Part1], Section 3.2.6> 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 7.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
In the collected ABNF below, list rules are expanded as per Section
1.2 of [Part1].
Accept-Ranges = acceptable-ranges Accept-Ranges = acceptable-ranges
Content-Range = byte-content-range / other-content-range Content-Range = byte-content-range / other-content-range
HTTP-date = <HTTP-date, defined in [Part2], Section 7.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.3> OWS = <OWS, defined in [Part1], Section 3.2.3>
skipping to change at page 23, line 49 skipping to change at page 23, line 49
o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
consideration: range flooding" consideration: range flooding"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
heuristic caching for new status codes" heuristic caching for new status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
limitations to Range to reduce its use as a denial-of-service limitations to Range to reduce its use as a denial-of-service
tool" tool"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/407>: "416 and
multipart/byteranges"
E.4. Since draft-ietf-httpbis-p5-range-22
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
expansion in ABNF appendices"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/437>: "incorrect
example dates"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type
registration template issues"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/462>: "Editorial
suggestions"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/485>: "MUSTs and
other feedback"
Index Index
2 2
206 Partial Content (status code) 10 206 Partial Content (status code) 10
4 4
416 Range Not Satisfiable (status code) 15 416 Range Not Satisfiable (status code) 15
A A
Accept-Ranges header field 7 Accept-Ranges header field 7
 End of changes. 28 change blocks. 
44 lines changed or deleted 79 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/