< draft-ietf-httpbis-p5-range-20.txt   draft-ietf-httpbis-p5-range-21.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: January 17, 2013 J. Reschke, Ed. Expires: April 7, 2013 J. Reschke, Ed.
greenbytes greenbytes
July 16, 2012 October 4, 2012
HTTP/1.1, part 5: Range Requests Hypertext Transfer Protocol (HTTP/1.1): Range Requests
draft-ietf-httpbis-p5-range-20 draft-ietf-httpbis-p5-range-21
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.1. The changes in this draft are summarized in Appendix E.2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on April 7, 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 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 7
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
6.2. Header Field Registration . . . . . . . . . . . . . . . . 15 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 20 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) . . . . . . . . . . . . . . . . . . . . 22
E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22 E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22
E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 22
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
HTTP clients often encounter interrupted data transfers as a result HTTP clients often encounter interrupted data transfers as a result
of canceled 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
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 specification targets conformance criteria according to the role Conformance criteria and considerations regarding error handling are
of a participant in HTTP communication. Hence, HTTP requirements are defined in Section 2.5 of [Part1].
placed on senders, recipients, clients, servers, user agents,
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
the requirements associated with the roles it partakes in HTTP. Note
that SHOULD-level requirements are relevant here, unless one of the
documented exceptions is applicable.
This document also uses ABNF to define valid protocol elements
(Section 1.2). In addition to the prose requirements placed upon
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, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to
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 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
skipping to change at page 12, line 37 skipping to change at page 12, line 4
representation using a 200 (OK) response. representation using a 200 (OK) response.
5.4. Range 5.4. Range
5.4.1. Byte Ranges 5.4.1. Byte Ranges
Since all HTTP representations are transferred as sequences of bytes, Since all HTTP representations are transferred as sequences of bytes,
the concept of a byte range is meaningful for any HTTP the concept of a byte range is meaningful for any HTTP
representation. (However, not all clients and servers need to representation. (However, not all clients and servers need to
support byte-range operations.) support byte-range operations.)
Byte range specifications in HTTP apply to the sequence of bytes in Byte range specifications in HTTP apply to the sequence of bytes in
the representation body (not necessarily the same as the message the representation data (not necessarily the same as the message
body). body).
A byte range operation MAY specify a single range of bytes, or a set A byte range operation MAY specify a single range of bytes, or a set
of ranges within a single representation. of ranges within a single representation.
byte-ranges-specifier = bytes-unit "=" byte-range-set byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ] byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
first-byte-pos = 1*DIGIT first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT
skipping to change at page 13, line 16 skipping to change at page 12, line 30
positions specified are inclusive. Byte offsets start at zero. positions specified are inclusive. Byte offsets start at zero.
If the last-byte-pos value is present, it MUST be greater than or If the last-byte-pos value is present, it MUST be greater than or
equal to the first-byte-pos in that byte-range-spec, or the byte- equal to the first-byte-pos in that byte-range-spec, or the byte-
range-spec is syntactically invalid. The recipient of a byte-range- range-spec is syntactically invalid. The recipient of a byte-range-
set that includes one or more syntactically invalid byte-range-spec set that includes one or more syntactically invalid byte-range-spec
values MUST ignore the header field that includes that byte-range- values MUST ignore the header field that includes that byte-range-
set. set.
If the last-byte-pos value is absent, or if the value is greater than If the last-byte-pos value is absent, or if the value is greater than
or equal to the current length of the representation body, last-byte- or equal to the current length of the representation data, last-byte-
pos is taken to be equal to one less than the current length of the pos is taken to be equal to one less than the current length of the
representation in bytes. representation in bytes.
By its choice of last-byte-pos, a client can limit the number of By its choice of last-byte-pos, a client can limit the number of
bytes retrieved without knowing the size of the representation. bytes retrieved without knowing the size of the representation.
suffix-byte-range-spec = "-" suffix-length suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
A suffix-byte-range-spec is used to specify the suffix of the A suffix-byte-range-spec is used to specify the suffix of the
representation body, of a length given by the suffix-length value. representation data, of a length given by the suffix-length value.
(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
skipping to change at page 14, line 35 skipping to change at page 13, line 47
o Several legal but not canonical specifications of the second 500 o Several legal but not canonical specifications of the second 500
bytes (byte offsets 500-999, inclusive): bytes (byte offsets 500-999, inclusive):
bytes=500-600,601-999 bytes=500-600,601-999
bytes=500-700,601-999 bytes=500-700,601-999
5.4.2. Range Retrieval Requests 5.4.2. Range Retrieval Requests
The "Range" header field defines the GET method (conditional or not) The "Range" header field defines the GET method (conditional or not)
to request one or more sub-ranges of the response representation to request one or more sub-ranges of the response representation
body, instead of the entire representation body. data, instead of the entire representation data.
Range = byte-ranges-specifier / other-ranges-specifier Range = byte-ranges-specifier / other-ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*CHAR other-range-set = 1*CHAR
A server MAY ignore the Range header field. However, origin servers A server MAY ignore the Range header field. However, origin servers
and intermediate caches ought to support byte ranges when possible, and intermediate caches ought to support byte ranges when possible,
since Range supports efficient recovery from partially failed since Range supports efficient recovery from partially failed
transfers, and supports efficient partial retrieval of large transfers, and supports efficient partial retrieval of large
representations. representations.
skipping to change at page 16, line 50 skipping to change at page 16, line 19
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. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 1: Message Routing and Syntax"", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-20 (work in progress), draft-ietf-httpbis-p1-messaging-21 (work in progress),
July 2012. October 2012.
[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 2: Semantics and Payloads", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-20 (work in progress), draft-ietf-httpbis-p2-semantics-21 (work in progress),
July 2012. October 2012.
[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 4: Conditional Requests", Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-20 (work in progress), draft-ietf-httpbis-p4-conditional-21 (work in progress),
July 2012. October 2012.
[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-20 (work in progress), draft-ietf-httpbis-p6-cache-21 (work in progress),
July 2012. October 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 20, line 24 skipping to change at page 19, line 45
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) 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
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. 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
skipping to change at page 20, line 49 skipping to change at page 20, line 18
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.1>
token = <token, defined in [Part1], Section 3.2.4> token = <token, defined in [Part1], Section 3.2.4>
The rules below are defined in other parts: The rules below are defined in other parts:
HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8.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-spec / other-content-range-spec
HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8.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.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"
skipping to change at page 22, line 30 skipping to change at page 22, line 30
o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve
'none' as byte range unit" 'none' as byte range unit"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
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
o Conformance criteria and considerations regarding error handling
are now defined in Part 1.
Index Index
2 2
206 Partial Content (status code) 6 206 Partial Content (status code) 5
4 4
416 Requested Range Not Satisfiable (status code) 7 416 Requested Range Not Satisfiable (status code) 6
A A
Accept-Ranges header field 9 Accept-Ranges header field 8
C C
Content-Range header field 10 Content-Range header field 9
G G
Grammar Grammar
Accept-Ranges 9 Accept-Ranges 8
acceptable-ranges 9 acceptable-ranges 8
byte-content-range-spec 10 byte-content-range-spec 9
byte-range-resp-spec 10 byte-range-resp-spec 9
byte-range-set 12 byte-range-set 12
byte-range-spec 12 byte-range-spec 12
byte-ranges-specifier 12 byte-ranges-specifier 12
bytes-unit 5 bytes-unit 5
Content-Range 10 Content-Range 9
first-byte-pos 12 first-byte-pos 12
If-Range 11 If-Range 11
instance-length 10 instance-length 9
last-byte-pos 12 last-byte-pos 12
other-range-unit 5 other-range-unit 5
Range 14 Range 13
range-unit 5 range-unit 5
ranges-specifier 12 ranges-specifier 12
suffix-byte-range-spec 13 suffix-byte-range-spec 12
suffix-length 13 suffix-length 12
H
Header Fields
Accept-Ranges 9
Content-Range 10
If-Range 11
Range 12
I I
If-Range header field 11 If-Range header field 10
M M
Media Type Media Type
multipart/byteranges 18 multipart/byteranges 17
multipart/x-byteranges 20 multipart/x-byteranges 19
multipart/byteranges Media Type 18 multipart/byteranges Media Type 17
multipart/x-byteranges Media Type 20 multipart/x-byteranges Media Type 19
R R
Range header field 12 Range header field 11
S
Status Codes
206 Partial Content 6
416 Requested Range Not Satisfiable 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. 36 change blocks. 
119 lines changed or deleted 77 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/
X-Generator: pyht 0.35