draft-ietf-httpbis-p5-range-16.txt   draft-ietf-httpbis-p5-range-17.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: February 25, 2012 J. Mogul Expires: May 3, 2012 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 24, 2011 October 31, 2011
HTTP/1.1, part 5: Range Requests and Partial Responses HTTP/1.1, part 5: Range Requests and Partial Responses
draft-ietf-httpbis-p5-range-16 draft-ietf-httpbis-p5-range-17
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. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 5 of the information initiative since 1990. This document is Part 5 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group 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.17. The changes in this draft are summarized in Appendix D.18.
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 February 25, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 52 skipping to change at page 2, line 52
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 6 Specification . . . . . . . . . . . . . . . . . . . . 6
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 7
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8
4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 16
6.2. Header Field Registration . . . . . . . . . . . . . . . . 16 6.2. Header Field Registration . . . . . . . . . . . . . . . . 16
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
Appendix B. Compatibility with Previous Versions . . . . . . . . 20 Appendix B. Compatibility with Previous Versions . . . . . . . . 21
B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 21
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 22
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 22 publication) . . . . . . . . . . . . . . . . . . . . 23
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 23
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 23
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 23
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 24
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 24
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 24
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 24
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 25
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 25
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 25
D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 25
D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 25
D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 26
D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 26
D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25 D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 26
D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25 D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 26
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 26
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 cancelled 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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
that do not implement this feature can respond as if it is a normal that do not implement this feature can respond as if it is a normal
GET request without impacting interoperability. Partial responses GET request without impacting interoperability. Partial responses
are indicated by a distinct status code to not be mistaken for full are indicated by a distinct status code to not be mistaken for full
responses by intermediate caches that might not implement the responses by intermediate caches that might not implement the
feature. feature.
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. Requirements 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].
An implementation is not compliant if it fails to satisfy one or more This document defines conformance criteria for several roles in HTTP
of the "MUST" or "REQUIRED" level requirements for the protocols it communication, including Senders, Recipients, Clients, Servers, User-
implements. An implementation that satisfies all the "MUST" or Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
"REQUIRED" level and all the "SHOULD" level requirements for its Section 2 of [Part1] for definitions of these terms.
protocols is said to be "unconditionally compliant"; one that
satisfies all the "MUST" level requirements but not all the "SHOULD" An implementation is considered conformant if it complies with all of
level requirements for its protocols is said to be "conditionally the requirements associated with its role(s). Note that SHOULD-level
compliant". 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 are invalid.
Unless noted otherwise, Recipients MAY take steps to recover a usable
protocol element from an invalid construct. However, HTTP does not
define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error
recovery could lead to dangerous consequences.
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix C shows the collected ABNF, with the list rule rule). Appendix C shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (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 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible USASCII character), sequence of data), SP (space), and VCHAR (any visible US-ASCII
and WSP (whitespace). 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 1.2.1. Core Rules
The core rules below are defined in [Part1]: The core rules below are defined in [Part1] and [Part2]:
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.3>
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
1.2.2. ABNF Rules defined in other Parts of the Specification 1.2.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
entity-tag = <entity-tag, defined in [Part4], Section 2.3> 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
skipping to change at page 10, line 44 skipping to change at page 11, line 9
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
do not explicitly describe its semantic. Currently, only status
codes 206 (Partial Content) and 416 (Requested range not satisfiable)
describe the meaning of this header field.
Examples of byte-content-range-spec values, assuming that the 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:
bytes 500-999/1234 bytes 500-999/1234
skipping to change at page 17, line 15 skipping to change at page 17, line 31
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 may 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 12 of [Part1]. See Section 11 of [Part1].
9. References 9. References
9.1. Normative References 9.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-16 and Message Parsing", draft-ietf-httpbis-p1-messaging-17
(work in progress), August 2011. (work in progress), October 2011.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
progress), October 2011.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-16 (work in Requests", draft-ietf-httpbis-p4-conditional-17 (work in
progress), August 2011. progress), October 2011.
[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 21, line 11 skipping to change at page 22, line 11
Clarify that multipart/byteranges can consist of a single part. Clarify that multipart/byteranges can consist of a single part.
(Appendix A) (Appendix A)
Appendix C. Collected ABNF Appendix C. Collected ABNF
Accept-Ranges = 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 [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
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 25, line 30 skipping to change at page 26, line 30
None. None.
D.17. Since draft-ietf-httpbis-p5-range-15 D.17. Since draft-ietf-httpbis-p5-range-15
Closed issues: Closed issues:
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
consideration: range flooding" consideration: range flooding"
D.18. Since draft-ietf-httpbis-p5-range-16
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy"
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"
Index Index
2 2
206 Partial Content (status code) 7 206 Partial Content (status code) 7
4 4
416 Requested Range Not Satisfiable (status code) 7 416 Requested Range Not Satisfiable (status code) 8
A A
Accept-Ranges header field 9 Accept-Ranges header field 9
C C
Content-Range header field 9 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 13
byte-range-spec 13 byte-range-spec 13
byte-ranges-specifier 13 byte-ranges-specifier 13
skipping to change at page 26, line 20 skipping to change at page 27, line 33
other-range-unit 6 other-range-unit 6
Range 15 Range 15
range-unit 6 range-unit 6
ranges-specifier 13 ranges-specifier 13
suffix-byte-range-spec 14 suffix-byte-range-spec 14
suffix-length 14 suffix-length 14
H H
Header Fields Header Fields
Accept-Ranges 9 Accept-Ranges 9
Content-Range 9 Content-Range 10
If-Range 12 If-Range 12
Range 13 Range 13
I I
If-Range header field 12 If-Range header field 12
M M
Media Type Media Type
multipart/byteranges 18 multipart/byteranges 18
multipart/x-byteranges 20 multipart/x-byteranges 21
multipart/byteranges Media Type 18 multipart/byteranges Media Type 18
multipart/x-byteranges Media Type 20 multipart/x-byteranges Media Type 21
R R
Range header field 13 Range header field 13
S S
Status Codes Status Codes
206 Partial Content 7 206 Partial Content 7
416 Requested Range Not Satisfiable 7 416 Requested Range Not Satisfiable 8
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. 32 change blocks. 
62 lines changed or deleted 104 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/