draft-ietf-httpbis-p5-range-19.txt   draft-ietf-httpbis-p5-range-20.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: September 13, 2012 J. Reschke, Ed. Expires: January 17, 2013 J. Reschke, Ed.
greenbytes greenbytes
March 12, 2012 July 16, 2012
HTTP/1.1, part 5: Range Requests and Partial Responses HTTP/1.1, part 5: Range Requests
draft-ietf-httpbis-p5-range-19 draft-ietf-httpbis-p5-range-20
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. HTTP has been in use by the World Wide Web global systems. This document defines range requests and the rules for
information initiative since 1990. This document is Part 5 of the constructing and combining responses to those requests.
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616.
Part 5 defines range-specific requests and the rules for 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 should take place on the HTTPBIS working Discussion of this draft takes place on the HTTPBIS working group
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 D.20. The changes in this draft are summarized in Appendix E.1.
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 September 13, 2012. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 42 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 5
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7
4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7
4.1. Response to a Single and Multiple Ranges Request . . . . . 7 4.1. Response to a Single and Multiple Ranges Request . . . . . 7
4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 8 4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 8
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 22 skipping to change at page 3, line 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Internet Media Type multipart/byteranges . . . . . . 17 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 20
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 22 publication) . . . . . . . . . . . . . . . . . . . . 22
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25
D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 25
D.19. Since draft-ietf-httpbis-p5-range-17 . . . . . . . . . . . 25
D.20. Since draft-ietf-httpbis-p5-range-18 . . . . . . . . . . . 25
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
HTTP clients often encounter interrupted data transfers as a result HTTP clients often encounter interrupted data transfers as a result
of cancelled requests or dropped connections. When a client has of canceled requests or dropped connections. When a client has
stored a partial representation, it is desirable to request the stored a partial representation, it is desirable to request the
remainder of that representation in a subsequent request rather than remainder of that representation in a subsequent request rather than
transfer the entire representation. There are also a number of Web transfer the entire representation. There are also a number of Web
applications that benefit from being able to request only a subset of applications that benefit from being able to request only a subset of
a larger representation, such as a single page of a very large a larger representation, such as a single page of a very large
document or only part of an image to be rendered by a device with document or only part of an image to be rendered by a device with
limited local storage. limited local storage.
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. The protocol for range requests
skipping to change at page 4, line 36 skipping to change at page 4, line 36
Although the HTTP range request mechanism is designed to allow for Although the HTTP 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].
This document defines conformance criteria for several roles in HTTP This specification targets conformance criteria according to the role
communication, including Senders, Recipients, Clients, Servers, User- of a participant in HTTP communication. Hence, HTTP requirements are
Agents, Origin Servers, Intermediaries, Proxies and Gateways. See placed on senders, recipients, clients, servers, user agents,
Section 2 of [Part1] for definitions of these terms. intermediaries, origin servers, proxies, gateways, or caches,
depending on what behavior is being constrained by the requirement.
See Section 2 of [Part1] for definitions of these terms.
The verb "generate" is used instead of "send" where a requirement
differentiates between creating a protocol element and merely
forwarding a received element downstream.
An implementation is considered conformant if it complies with all of An implementation is considered conformant if it complies with all of
the requirements associated with its role(s). Note that SHOULD-level the requirements associated with the roles it partakes in HTTP. Note
requirements are relevant here, unless one of the documented that SHOULD-level requirements are relevant here, unless one of the
exceptions is applicable. documented exceptions is applicable.
This document also uses ABNF to define valid protocol elements This document also uses ABNF to define valid protocol elements
(Section 1.2). In addition to the prose requirements placed upon (Section 1.2). In addition to the prose requirements placed upon
them, Senders MUST NOT generate protocol elements that are invalid. them, senders MUST NOT generate protocol elements that do not match
the grammar defined by the ABNF rules for those protocol elements
that are applicable to the sender's role. If a received protocol
element is processed, the recipient MUST be able to parse any value
that would match the ABNF rules for that protocol element, excluding
only those rules not applicable to the recipient's role.
Unless noted otherwise, Recipients MAY take steps to recover a usable Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. However, HTTP does not protocol element from an invalid construct. HTTP does not define
define specific error handling mechanisms, except in cases where it specific error handling mechanisms except when they have a direct
has direct impact on security. This is because different uses of the impact on security, since different applications of the protocol
protocol require different error handling strategies; for example, a require different error handling strategies. For example, a Web
Web browser may wish to transparently recover from a response where browser might wish to transparently recover from a response where the
the Location header field doesn't parse according to the ABNF, Location header field doesn't parse according to the ABNF, whereas a
whereby in a systems control protocol using HTTP, this type of error systems control client might consider any form of error recovery to
recovery could lead to dangerous consequences. be dangerous.
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 shows the collected ABNF with the list 1.2 of [Part1]. Appendix C describes rules imported from other
rule expanded. documents. Appendix D shows the collected ABNF with the list rule
expanded.
The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), 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 8-bit
sequence of data), SP (space), and VCHAR (any visible US-ASCII
character).
Note that all rules derived from token are to be compared case-
insensitively, like range-unit and acceptable-ranges.
1.2.1. Core Rules
The core rules below are defined in [Part1] and [Part2]:
OWS = <OWS, defined in [Part1], Section 3.2.1>
token = <token, defined in [Part1], Section 3.2.4>
HTTP-date = <HTTP-date, defined in [Part2], Section 8>
1.2.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts:
entity-tag = <entity-tag, defined in [Part4], Section 2.3>
2. Range Units 2. Range Units
HTTP/1.1 allows a client to request that only part (a range) of the HTTP/1.1 allows a client to request that only part (a range) of the
representation be included within the response. HTTP/1.1 uses range representation be included within the response. HTTP/1.1 uses range
units in the Range (Section 5.4) and Content-Range (Section 5.2) units in the Range (Section 5.4) and Content-Range (Section 5.2)
header fields. A representation can be broken down into subranges header fields. A representation can be broken down into subranges
according to various structural units. according to various structural units.
range-unit = bytes-unit / other-range-unit range-unit = bytes-unit / other-range-unit
skipping to change at page 7, line 7 skipping to change at page 6, line 44
o Either a Content-Range header field (Section 5.2) indicating the o Either a Content-Range header field (Section 5.2) indicating the
range included with this response, or a multipart/byteranges range included with this response, or a multipart/byteranges
Content-Type including Content-Range fields for each part. If a Content-Type including Content-Range fields for each part. If a
Content-Length header field is present in the response, its value Content-Length header field is present in the response, its value
MUST match the actual number of octets transmitted in the message MUST match the actual number of octets transmitted in the message
body. body.
o Date o Date
o Cache-Control, ETag, Expires, Content-Location, Last-Modified, o Cache-Control, ETag, Expires, Content-Location and/or Vary, if the
and/or Vary, if the header field would have been sent in a 200 header field would have been sent in a 200 (OK) response to the
response to the same request same request
If the 206 response is the result of an If-Range request, the If a 206 is sent in response to a request with an If-Range header
response SHOULD NOT include other representation header fields. field, it SHOULD NOT include other representation header fields.
Otherwise, the response MUST include all of the representation header Otherwise, the response MUST include all of the representation header
fields that would have been returned with a 200 (OK) response to the fields that would have been returned with a 200 (OK) response to the
same request. same request.
Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to
determine freshness for 206 responses. determine freshness for 206 responses.
3.2. 416 Requested Range Not Satisfiable 3.2. 416 Requested Range Not Satisfiable
A server SHOULD return a response with this status code if a request A server SHOULD return a response with this status code if a request
included a Range header field (Section 5.4), and none of the ranges- included a Range header field (Section 5.4), and none of the ranges-
specifier values in this field overlap the current extent of the specifier values in this field overlap the current extent of the
selected resource, and the request did not include an If-Range header selected resource, and the request did not include an If-Range header
field (Section 5.3). (For byte-ranges, this means that the first- 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 byte-pos of all of the byte-range-spec values were greater than the
skipping to change at page 7, line 42 skipping to change at page 7, line 30
current length of the representation (see Section 5.2). This current length of the representation (see Section 5.2). This
response MUST NOT use the multipart/byteranges content-type. For response MUST NOT use the multipart/byteranges content-type. For
example, example,
HTTP/1.1 416 Requested Range Not Satisfiable HTTP/1.1 416 Requested Range Not Satisfiable
Date: Mon, 20 Jan 2012 15:41:54 GMT Date: Mon, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022 Content-Range: bytes */47022
Content-Type: image/gif Content-Type: image/gif
Note: Clients cannot depend on servers to send a 416 (Requested Note: Clients cannot depend on servers to send a 416 (Requested
range not satisfiable) response instead of a 200 (OK) response for Range Not Satisfiable) response instead of a 200 (OK) response for
an unsatisfiable Range header field, since not all servers an unsatisfiable Range header field, since not all servers
implement this header field. implement this header field.
4. Responses to a Range Request 4. Responses to a Range Request
4.1. Response to a Single and Multiple Ranges Request 4.1. Response to a Single and Multiple Ranges Request
When an HTTP message includes the content of a single range (for When an HTTP message includes the content of a single range (for
example, a response to a request for a single range, or to a request example, a response to a request for a single range, or to a request
for a set of ranges that overlap without any holes), this content is for a set of ranges that overlap without any holes), this content is
skipping to change at page 8, line 22 skipping to change at page 8, line 10
Content-Length: 26012 Content-Length: 26012
Content-Type: image/gif Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping example, a response to a request for multiple non-overlapping
ranges), these are transmitted as a multipart message. The multipart ranges), these are transmitted as a multipart message. The multipart
media type used for this purpose is "multipart/byteranges" as defined media type used for this purpose is "multipart/byteranges" as defined
in Appendix A. in Appendix A.
A server MAY combine requested ranges when those ranges are A server MAY combine requested ranges when those ranges are
overlapping (see Section 7). overlapping (see Section 7.1).
A response to a request for a single range MUST NOT be sent using the A response to a request for a single range MUST NOT be sent using the
multipart/byteranges media type. A response to a request for multipart/byteranges media type. A response to a request for
multiple ranges, whose result is a single range, MAY be sent as a multiple ranges, whose result is a single range, MAY be sent as a
multipart/byteranges media type with one part. A client that cannot multipart/byteranges media type with one part. A client that cannot
decode a multipart/byteranges message MUST NOT ask for multiple decode a multipart/byteranges message MUST NOT ask for multiple
ranges in a single request. ranges in a single request.
When a client requests multiple ranges in one request, the server When a client asks for multiple ranges in one request, the server
SHOULD return them in the order that they appeared in the request. SHOULD return them in the order that they appeared in the request.
4.2. Combining Ranges 4.2. Combining Ranges
A response might transfer only a subrange of a representation if the A response might transfer only a subrange of a representation if the
connection closed prematurely or if the request used one or more connection closed prematurely or if the request used one or more
Range specifications. After several such transfers, a client might Range specifications. After several such transfers, a client might
have received several ranges of the same representation. These have received several ranges of the same representation. These
ranges can only be safely combined if they all have in common the ranges can only be safely combined if they all have in common the
same strong validator, where "strong validator" is defined to be same strong validator, where "strong validator" is defined to be
skipping to change at page 11, line 6 skipping to change at page 10, line 46
absolute byte positions for both the first and last byte of the absolute byte positions for both the first and last byte of the
range. range.
A byte-content-range-spec with a byte-range-resp-spec whose last- A byte-content-range-spec with a byte-range-resp-spec whose last-
byte-pos value is less than its first-byte-pos value, or whose byte-pos value is less than its first-byte-pos value, or whose
instance-length value is less than or equal to its last-byte-pos instance-length value is less than or equal to its last-byte-pos
value, is invalid. The recipient of an invalid byte-content-range- value, is invalid. The recipient of an invalid byte-content-range-
spec MUST ignore it and any content transferred along with it. spec MUST ignore it and any content transferred along with it.
In the case of a byte range request: A server sending a response with In the case of a byte range request: A server sending a response with
status code 416 (Requested range not satisfiable) SHOULD include a status code 416 (Requested Range Not Satisfiable) SHOULD include a
Content-Range field with a byte-range-resp-spec of "*". The Content-Range field with a byte-range-resp-spec of "*". The
instance-length specifies the current length of the selected instance-length specifies the current length of the selected
resource. A response with status code 206 (Partial Content) MUST NOT resource. A response with status code 206 (Partial Content) MUST NOT
include a Content-Range field with a byte-range-resp-spec of "*". include a Content-Range field with a byte-range-resp-spec of "*".
The "Content-Range" header field has no meaning for status codes that The "Content-Range" header field has no meaning for status codes that
do not explicitly describe its semantic. Currently, only status do not explicitly describe its semantic. Currently, only status
codes 206 (Partial Content) and 416 (Requested range not satisfiable) codes 206 (Partial Content) and 416 (Requested Range Not Satisfiable)
describe the meaning of this header field. describe the meaning of this header field.
Examples of byte-content-range-spec values, assuming that the Examples of byte-content-range-spec values, assuming that the
representation contains a total of 1234 bytes: representation contains a total of 1234 bytes:
o The first 500 bytes: o The first 500 bytes:
bytes 0-499/1234 bytes 0-499/1234
o The second 500 bytes: o The second 500 bytes:
skipping to change at page 11, line 37 skipping to change at page 11, line 28
o All except for the first 500 bytes: o All except for the first 500 bytes:
bytes 500-1233/1234 bytes 500-1233/1234
o The last 500 bytes: o The last 500 bytes:
bytes 734-1233/1234 bytes 734-1233/1234
If the server ignores a byte-range-spec (for example if it is If the server ignores a byte-range-spec (for example if it is
syntactically invalid, or if it may be seen as a denial-of-service syntactically invalid, or if it might be seen as a denial-of-service
attack), the server SHOULD treat the request as if the invalid Range attack), the server SHOULD treat the request as if the invalid Range
header field did not exist. (Normally, this means return a 200 header field did not exist. (Normally, this means return a 200 (OK)
response containing the full representation). response containing the full representation).
5.3. If-Range 5.3. 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
skipping to change at page 13, line 46 skipping to change at page 13, line 38
(That is, this form specifies the last N bytes of a representation.) (That is, this form specifies the last N bytes of a representation.)
If the representation is shorter than the specified suffix-length, If the representation is shorter than the specified suffix-length,
the entire representation is used. the entire representation is used.
If a syntactically valid byte-range-set includes at least one byte- If a syntactically valid byte-range-set includes at least one byte-
range-spec whose first-byte-pos is less than the current length of range-spec whose first-byte-pos is less than the current length of
the representation, or at least one suffix-byte-range-spec with a the representation, or at least one suffix-byte-range-spec with a
non-zero suffix-length, then the byte-range-set is satisfiable. non-zero suffix-length, then the byte-range-set is satisfiable.
Otherwise, the byte-range-set is unsatisfiable. If the byte-range- Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
set is unsatisfiable, the server SHOULD return a response with a 416 set is unsatisfiable, the server SHOULD return a response with a 416
(Requested range not satisfiable) status code. Otherwise, the server (Requested Range Not Satisfiable) status code. Otherwise, the server
SHOULD return a response with a 206 (Partial Content) status code SHOULD return a response with a 206 (Partial Content) status code
containing the satisfiable ranges of the representation. containing the satisfiable ranges of the representation.
In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-
length are expressed as decimal number of octets. Since there is no
predefined limit to the length of an HTTP payload, recipients SHOULD
anticipate potentially large decimal numerals and prevent parsing
errors due to integer conversion overflows.
Examples of byte-ranges-specifier values (assuming a representation Examples of byte-ranges-specifier values (assuming a representation
of length 10000): of length 10000):
o The first 500 bytes (byte offsets 0-499, inclusive): o The first 500 bytes (byte offsets 0-499, inclusive):
bytes=0-499 bytes=0-499
o The second 500 bytes (byte offsets 500-999, inclusive): o The second 500 bytes (byte offsets 500-999, inclusive):
bytes=500-999 bytes=500-999
skipping to change at page 16, line 15 skipping to change at page 16, line 15
6.3. Range Specifier Registration 6.3. Range Specifier Registration
The registration procedure for HTTP Range Specifiers is defined by The registration procedure for HTTP Range Specifiers is defined by
Section 2.1 of this document. Section 2.1 of this document.
The HTTP Range Specifier Registry shall be created at The HTTP Range Specifier Registry shall be created at
<http://www.iana.org/assignments/http-range-specifiers> and be <http://www.iana.org/assignments/http-range-specifiers> and be
populated with the registrations below: populated with the registrations below:
+----------------------+-------------------+----------------------+ +---------------+-------------------------------------+-------------+
| Range Specifier Name | Description | Reference | | Range | Description | Reference |
+----------------------+-------------------+----------------------+ | Specifier | | |
| bytes | a range of octets | (this specification) | | 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 The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
7. Security Considerations 7. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
7.1. Overlapping Ranges 7.1. Overlapping Ranges
Range requests containing overlapping ranges may lead to the Range requests containing overlapping ranges can lead to the
situation where a server is sending far more data than the size of situation where a server is sending far more data than the size of
the complete resource representation. the complete resource representation.
8. Acknowledgments 8. Acknowledgments
See Section 9 of [Part1]. See Section 9 of [Part1].
9. References 9. References
9.1. Normative References 9.1. Normative References
[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 1: URIs, Connections, and Message "HTTP/1.1, part 1: Message Routing and Syntax"",
Parsing", draft-ietf-httpbis-p1-messaging-19 (work in draft-ietf-httpbis-p1-messaging-20 (work in progress),
progress), March 2012. July 2012.
[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 2: Message Semantics", "HTTP/1.1, part 2: Semantics and Payloads",
draft-ietf-httpbis-p2-semantics-19 (work in progress), draft-ietf-httpbis-p2-semantics-20 (work in progress),
March 2012. July 2012.
[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 4: Conditional Requests", "HTTP/1.1, part 4: Conditional Requests",
draft-ietf-httpbis-p4-conditional-19 (work in progress), draft-ietf-httpbis-p4-conditional-20 (work in progress),
March 2012. July 2012.
[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-19 (work in progress), draft-ietf-httpbis-p6-cache-20 (work in progress),
March 2012. July 2012.
[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 18, line 6 skipping to change at page 18, line 14
Appendix A. Internet Media Type multipart/byteranges Appendix A. Internet Media Type multipart/byteranges
When an HTTP 206 (Partial Content) response message includes the When an HTTP 206 (Partial Content) response message includes the
content of multiple ranges (a response to a request for multiple non- content of multiple ranges (a response to a request for multiple non-
overlapping ranges), these are transmitted as a multipart message overlapping ranges), these are transmitted as a multipart message
body ([RFC2046], Section 5.1). The media type for this purpose is body ([RFC2046], Section 5.1). The media type for this purpose is
called "multipart/byteranges". The following is to be registered called "multipart/byteranges". The following is to be registered
with IANA [RFC4288]. with IANA [RFC4288].
Note: Despite the name "multipart/byteranges" is not limited to
the byte ranges only.
The multipart/byteranges media type includes one or more parts, each The multipart/byteranges media type includes one or more parts, each
with its own Content-Type and Content-Range fields. The required with its own Content-Type and Content-Range fields. The required
boundary parameter specifies the boundary string used to separate boundary parameter specifies the boundary string used to separate
each body-part. each body-part.
Type name: multipart Type name: multipart
Subtype name: byteranges Subtype name: byteranges
Required parameters: boundary Required parameters: boundary
skipping to change at page 18, line 31 skipping to change at page 18, line 36
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: none Security considerations: none
Interoperability considerations: none Interoperability considerations: none
Published specification: This specification (see Appendix A). Published specification: This specification (see Appendix A).
Applications that use this media type: Applications that use this media type: HTTP components supporting
multiple ranges in a single request.
Additional information: Additional information:
Magic number(s): none Magic number(s): none
File extension(s): none File extension(s): none
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/Change controller: IESG
Note: Despite the name "multipart/byteranges" is not limited to
the byte ranges only.
For example: 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
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-type: application/pdf Content-type: application/pdf
Content-range: bytes 500-999/8000 Content-range: bytes 500-999/8000
...the first range... ...the first range...
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-type: application/pdf Content-type: application/pdf
Content-range: bytes 7000-7999/8000 Content-range: bytes 7000-7999/8000
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
Other example: Another example, using the "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-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
skipping to change at page 20, line 5 skipping to change at page 20, line 12
Notes: Notes:
1. Additional CRLFs MAY precede the first boundary string in the 1. Additional CRLFs MAY 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.
3. A number of browsers and servers were coded to an early draft of 3. A number of clients and servers were coded to an early draft of
the byteranges specification to use a media type of multipart/ the byteranges specification to use a media type of multipart/
x-byteranges, which is almost, but not quite compatible with the x-byteranges, which is almost, but not quite compatible with the
version documented in HTTP/1.1. version documented in HTTP/1.1.
Appendix B. Changes from RFC 2616 Appendix B. Changes from RFC 2616
Introduce Range Specifier Registry. (Section 2.1)
Clarify that it is not ok to use a weak validator in a 206 response. Clarify that it is not ok to use a weak validator in a 206 response.
(Section 3.1) (Section 3.1)
Change ABNF productions for header fields to only define the field Change ABNF productions for header fields to only define the field
value. (Section 5) value. (Section 5)
Clarify that multipart/byteranges can consist of a single part. Clarify that multipart/byteranges can consist of a single part.
(Appendix A) (Appendix A)
Appendix C. Collected ABNF Appendix C. Imported ABNF
The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
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
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character).
Note that all rules derived from token are to be compared case-
insensitively, like range-unit and acceptable-ranges.
The rules below are defined in [Part1]:
OWS = <OWS, defined in [Part1], Section 3.2.1>
token = <token, defined in [Part1], Section 3.2.4>
The rules below are defined in other parts:
HTTP-date = <HTTP-date, defined in [Part2], Section 5.1>
entity-tag = <entity-tag, defined in [Part4], Section 2.3>
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-spec / other-content-range-spec
HTTP-date = <HTTP-date, defined in [Part2], Section 8> HTTP-date = <HTTP-date, defined in [Part2], Section 5.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.1>
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-spec = bytes-unit SP byte-range-resp-spec "/" (
instance-length / "*" ) instance-length / "*" )
byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
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"
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 instance-length = 1*DIGIT
skipping to change at page 22, line 4 skipping to change at page 22, line 4
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.4>
ABNF diagnostics:
; Accept-Ranges defined but not used
; Content-Range defined but not used
; If-Range defined but not used
; Range defined but not used
Appendix D. Change Log (to be removed by RFC Editor before publication)
D.1. Since RFC 2616
Extracted relevant partitions from [RFC2616].
D.2. Since draft-ietf-httpbis-p5-range-00
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
validators in 206 responses"
(<http://purl.org/NET/http-errata#ifrange206>)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
Informative references"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
to-date references"
D.3. Since draft-ietf-httpbis-p5-range-01
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
RFC4288"
Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Add explicit references to BNF syntax and rules imported from
other parts of the specification.
D.4. Since draft-ietf-httpbis-p5-range-02
Ongoing work on IANA Message Header Field Registration
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header field registrations for
headers defined in this document.
D.5. Since draft-ietf-httpbis-p5-range-03
None.
D.6. Since draft-ietf-httpbis-p5-range-04
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
byteranges minimum number of parts"
Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Use "/" instead of "|" for alternatives.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header
field value format definitions.
D.7. Since draft-ietf-httpbis-p5-range-05
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base
for *-byte-pos and suffix-length"
Ongoing work on Custom Ranges
(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
o Remove bias in favor of byte ranges; allow custom ranges in ABNF.
Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Add appendix containing collected and expanded ABNF, reorganize
ABNF introduction.
D.8. Since draft-ietf-httpbis-p5-range-06
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements"
D.9. Since draft-ietf-httpbis-p5-range-07
Closed issues:
o Fixed discrepancy in the If-Range definition about allowed
validators.
o <http://tools.ietf.org/wg/httpbis/trac/ticket/150>: "multipart/ Appendix E. Change Log (to be removed by RFC Editor before publication)
byteranges for custom range units"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/151>: "range unit
missing from other-ranges-specifier in Range header"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes"
D.10. Since draft-ietf-httpbis-p5-range-08
No significant changes.
D.11. Since draft-ietf-httpbis-p5-range-09
No significant changes.
D.12. Since draft-ietf-httpbis-p5-range-10
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
'Requested Variant'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
entity / representation / variant terminology"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections"
Ongoing work on Custom Ranges
(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
o Add IANA registry.
D.13. Since draft-ietf-httpbis-p5-range-11
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't
be required to serve ranges"
D.14. Since draft-ietf-httpbis-p5-range-12
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification"
D.15. Since draft-ietf-httpbis-p5-range-13
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields"
D.16. Since draft-ietf-httpbis-p5-range-14
None.
D.17. Since draft-ietf-httpbis-p5-range-15
Closed issues:
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security Changes up to the first Working Group Last Call draft are summarized
consideration: range flooding" in <http://tools.ietf.org/html/
draft-ietf-httpbis-p5-range-19#appendix-D>.
D.18. Since draft-ietf-httpbis-p5-range-16 E.1. Since draft-ietf-httpbis-p5-range-19
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document o <http://tools.ietf.org/wg/httpbis/trac/ticket/358>: "ABNF list
HTTP's error-handling philosophy" expansion code problem"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content-
Range on responses other than 206"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case
sensitivity of ranges in p5"
D.19. Since draft-ietf-httpbis-p5-range-17
None. o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
requirements for recipients"
D.20. Since draft-ietf-httpbis-p5-range-18 o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve
'none' as byte range unit"
Closed issues: o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
introduction of new IANA registries as normative changes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units
limitations to Range to reduce its use as a denial-of-service vs leading zeroes vs size"
tool"
Index Index
2 2
206 Partial Content (status code) 6 206 Partial Content (status code) 6
4 4
416 Requested Range Not Satisfiable (status code) 7 416 Requested Range Not Satisfiable (status code) 7
A A
skipping to change at page 26, line 26 skipping to change at page 22, line 50
C C
Content-Range header field 10 Content-Range header field 10
G G
Grammar Grammar
Accept-Ranges 9 Accept-Ranges 9
acceptable-ranges 9 acceptable-ranges 9
byte-content-range-spec 10 byte-content-range-spec 10
byte-range-resp-spec 10 byte-range-resp-spec 10
byte-range-set 13 byte-range-set 12
byte-range-spec 13 byte-range-spec 12
byte-ranges-specifier 13 byte-ranges-specifier 12
bytes-unit 5 bytes-unit 5
Content-Range 10 Content-Range 10
first-byte-pos 13 first-byte-pos 12
If-Range 12 If-Range 11
instance-length 10 instance-length 10
last-byte-pos 13 last-byte-pos 12
other-range-unit 5 other-range-unit 5
Range 14 Range 14
range-unit 5 range-unit 5
ranges-specifier 13 ranges-specifier 12
suffix-byte-range-spec 13 suffix-byte-range-spec 13
suffix-length 13 suffix-length 13
H H
Header Fields Header Fields
Accept-Ranges 9 Accept-Ranges 9
Content-Range 10 Content-Range 10
If-Range 11 If-Range 11
Range 12 Range 12
I I
If-Range header field 11 If-Range header field 11
M M
Media Type Media Type
multipart/byteranges 17 multipart/byteranges 18
multipart/x-byteranges 20 multipart/x-byteranges 20
multipart/byteranges Media Type 17 multipart/byteranges Media Type 18
multipart/x-byteranges Media Type 20 multipart/x-byteranges Media Type 20
R R
Range header field 12 Range header field 12
S S
Status Codes Status Codes
206 Partial Content 6 206 Partial Content 6
416 Requested Range Not Satisfiable 7 416 Requested Range Not Satisfiable 7
skipping to change at page 28, line 4 skipping to change at page 24, line 25
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
EMail: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760
Fax: +49 251 2807761
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 61 change blocks. 
321 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/