draft-ietf-httpbis-p5-range-13.txt   draft-ietf-httpbis-p5-range-14.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: September 15, 2011 J. Mogul Expires: October 20, 2011 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
March 14, 2011 April 18, 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-13 draft-ietf-httpbis-p5-range-14
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia 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. Part 5 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines
range-specific requests and the rules for constructing and combining range-specific requests and the rules for constructing and combining
responses to those requests. 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 should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org), which is archived at
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<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.14. The changes in this draft are summarized in Appendix D.15.
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 15, 2011. This Internet-Draft will expire on October 20, 2011.
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 3, line 24 skipping to change at page 3, line 27
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
6.2. Header Field Registration . . . . . . . . . . . . . . . . 14 6.2. Header Field Registration . . . . . . . . . . . . . . . . 14
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Internet Media Type multipart/byteranges . . . . . . 16 Appendix A. Internet Media Type multipart/byteranges . . . . . . 16
Appendix B. Compatibility with Previous Versions . . . . . . . . 19 Appendix B. Compatibility with Previous Versions . . . . . . . . 19
B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 21
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 20 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 21
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 21 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 22 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23
D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 22 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23
D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23
D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 23 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 24
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 24
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
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 cache has of cancelled requests or dropped connections. When a cache 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 24 skipping to change at page 5, line 24
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
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:
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
entity-tag = <entity-tag, defined in [Part4], Section 2> entity-tag = <entity-tag, defined in [Part4], Section 2.2>
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
bytes-unit = "bytes" bytes-unit = "bytes"
other-range-unit = token other-range-unit = token
HTTP/1.1 has been designed to allow implementations of applications HTTP/1.1 has been designed to allow implementations of applications
skipping to change at page 5, line 50 skipping to change at page 5, line 50
defined by HTTP/1.1 is "bytes". Additional specifiers can be defined defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
as described in Section 2.1. as described in Section 2.1.
If a range unit is not understood in a request, a server MUST ignore If a range unit is not understood in a request, a server MUST ignore
the whole Range header field (Section 5.4). If a range unit is not the whole Range header field (Section 5.4). If a range unit is not
understood in a response, an intermediary SHOULD pass the response to understood in a response, an intermediary SHOULD pass the response to
the client; a client MUST fail. the client; a client MUST fail.
2.1. Range Specifier Registry 2.1. Range Specifier Registry
The HTTP Ranger Specifier Registry defines the name space for the The HTTP Range Specifier Registry defines the name space for the
range specifier names. range specifier names.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
skipping to change at page 7, line 42 skipping to change at page 7, line 42
If a cache has a stored non-empty set of subranges for a If a cache has a stored non-empty set of subranges for a
representation, and an incoming response transfers another subrange, representation, and an incoming response transfers another subrange,
the cache MAY combine the new subrange with the existing set if both the cache MAY combine the new subrange with the existing set if both
the following conditions are met: the following conditions are met:
o Both the incoming response and the cache entry have a cache o Both the incoming response and the cache entry have a cache
validator. validator.
o The two cache validators match using the strong comparison o The two cache validators match using the strong comparison
function (see Section 4 of [Part4]). function (see Section 2.2.2 of [Part4]).
If either requirement is not met, the cache MUST use only the most If either requirement is not met, the cache MUST use only the most
recent partial response (based on the Date values transmitted with recent partial response (based on the Date values transmitted with
every response, and using the incoming response if these values are every response, and using the incoming response if these values are
equal or missing), and MUST discard the other partial information. equal or missing), and MUST discard the other partial information.
5. Header Field Definitions 5. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to range requests and partial responses. fields related to range requests and partial responses.
5.1. Accept-Ranges 5.1. Accept-Ranges
The "Accept-Ranges" header field allows a resource to indicate its The "Accept-Ranges" header field allows a resource to indicate its
acceptance of range requests. acceptance of range requests.
Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v Accept-Ranges = acceptable-ranges
Accept-Ranges-v = acceptable-ranges
acceptable-ranges = 1#range-unit / "none" acceptable-ranges = 1#range-unit / "none"
Origin servers that accept byte-range requests MAY send Origin servers that accept byte-range requests MAY send
Accept-Ranges: bytes Accept-Ranges: bytes
but are not required to do so. Clients MAY generate range requests but are not required to do so. Clients MAY generate range requests
without having received this header field for the resource involved. without having received this header field for the resource involved.
Range units are defined in Section 2. Range units are defined in Section 2.
skipping to change at page 8, line 37 skipping to change at page 8, line 36
to advise the client not to attempt a range request. to advise the client not to attempt a range request.
5.2. Content-Range 5.2. Content-Range
The "Content-Range" header field is sent with a partial The "Content-Range" header field is sent with a partial
representation to specify where in the full representation the representation to specify where in the full representation the
payload body is intended to be applied. payload body is intended to be applied.
Range units are defined in Section 2. Range units are defined in Section 2.
Content-Range = "Content-Range" ":" OWS Content-Range-v Content-Range = content-range-spec
Content-Range-v = content-range-spec
content-range-spec = byte-content-range-spec content-range-spec = byte-content-range-spec
/ other-content-range-spec / other-content-range-spec
byte-content-range-spec = bytes-unit SP byte-content-range-spec = bytes-unit SP
byte-range-resp-spec "/" 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)
/ "*" / "*"
skipping to change at page 11, line 14 skipping to change at page 11, line 11
(using either or both of If-Unmodified-Since and If-Match.) However, (using either or both of If-Unmodified-Since and If-Match.) However,
if the condition fails because the representation has been modified, if the condition fails because the representation has been modified,
the client would then have to make a second request to obtain the the client would then have to make a second request to obtain the
entire current representation. entire current representation.
The "If-Range" header field allows a client to "short-circuit" the The "If-Range" header field allows a client to "short-circuit" the
second request. Informally, its meaning is "if the representation is second request. Informally, its meaning is "if the representation is
unchanged, send me the part(s) that I am missing; otherwise, send me unchanged, send me the part(s) that I am missing; otherwise, send me
the entire new representation". the entire new representation".
If-Range = "If-Range" ":" OWS If-Range-v If-Range = entity-tag / HTTP-date
If-Range-v = entity-tag / HTTP-date
Only a strong validator (Section 2.2.2 of [Part4]) is usable for
range retrieval, since otherwise the client might end up with an
internally inconsistent representation. Clients MUST NOT use weak
validators in range requests. A cache or origin server receiving a
conditional range request MUST use the strong comparison function to
evaluate the condition.
If the client has no entity-tag for a representation, but does have a If the client has no entity-tag for a representation, but does have a
Last-Modified date, it MAY use that date in an If-Range header field. Last-Modified date, it MAY use that date in an If-Range header field.
(The server can distinguish between a valid HTTP-date and any form of (The server can distinguish between a valid HTTP-date and any form of
entity-tag by examining no more than two characters.) The If-Range entity-tag by examining no more than two characters.) The If-Range
header field SHOULD only be used together with a Range header field, header field SHOULD only be used together with a Range header field,
and MUST be ignored if the request does not include a Range header and MUST be ignored if the request does not include a Range header
field, or if the server does not support the sub-range operation. field, or if the server does not support the sub-range operation.
If a client wishes to perform a sub-range retrieval on a value for
which it has only a Last-Modified time and no opaque validator, it
MAY do this only if the Last-Modified time is strong in the sense
described in Section 2.1.2 of [Part4].
If the entity-tag given in the If-Range header field matches the If the entity-tag given in the If-Range header field matches the
current cache validator for the representation, then the server current cache validator for the representation, then the server
SHOULD provide the specified sub-range of the representation using a SHOULD provide the specified sub-range of the representation using a
206 (Partial Content) response. If the cache validator does not 206 (Partial Content) response. If the cache validator does not
match, then the server SHOULD return the entire representation using match, then the server SHOULD return the entire representation using
a 200 (OK) response. a 200 (OK) response.
5.4. Range 5.4. Range
5.4.1. Byte Ranges 5.4.1. Byte Ranges
skipping to change at page 13, line 33 skipping to change at page 13, line 40
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. body, instead of the entire representation body.
Range = "Range" ":" OWS Range-v Range = byte-ranges-specifier / other-ranges-specifier
Range-v = 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, HTTP/1.1 origin A server MAY ignore the Range header field. However, HTTP/1.1 origin
servers and intermediate caches ought to support byte ranges when servers and intermediate caches ought to support byte ranges when
possible, since Range supports efficient recovery from partially possible, since Range supports efficient recovery from partially
failed transfers, and supports efficient partial retrieval of large failed transfers, and supports efficient partial retrieval of large
representations. representations.
If the server supports the Range header field and the specified range If the server supports the Range header field and the specified range
skipping to change at page 15, line 38 skipping to change at page 16, line 4
8. Acknowledgments 8. Acknowledgments
Most of the specification of ranges is based on work originally done Most of the specification of ranges is based on work originally done
by Ari Luotonen and John Franks, with additional input from Steve by Ari Luotonen and John Franks, with additional input from Steve
Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
Rizzo, and Bill Weihl. Rizzo, and Bill Weihl.
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-13 and Message Parsing", draft-ietf-httpbis-p1-messaging-14
(work in progress), March 2011. (work in progress), April 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-13 (work in Requests", draft-ietf-httpbis-p4-conditional-14 (work in
progress), March 2011. progress), April 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 19, line 17 skipping to change at page 19, line 17
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. Compatibility with Previous Versions Appendix B. Compatibility with Previous Versions
B.1. Changes from RFC 2616 B.1. Changes from RFC 2616
Clarify that it is not ok to use a weak cache validator in a 206 Clarify that it is not ok to use a weak cache validator in a 206
response. (Section 3.1) response. (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. Collected ABNF Appendix C. Collected ABNF
Accept-Ranges = acceptable-ranges
Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v Content-Range = content-range-spec
Accept-Ranges-v = acceptable-ranges
Content-Range = "Content-Range:" OWS Content-Range-v
Content-Range-v = content-range-spec
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
If-Range = "If-Range:" OWS If-Range-v If-Range = entity-tag / HTTP-date
If-Range-v = entity-tag / HTTP-date
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Range = "Range:" OWS Range-v Range = byte-ranges-specifier / other-ranges-specifier
Range-v = 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"
content-range-spec = byte-content-range-spec / content-range-spec = byte-content-range-spec /
other-content-range-spec other-content-range-spec
entity-tag = <entity-tag, defined in [Part4], Section 2> entity-tag = <entity-tag, defined in [Part4], Section 2.2>
first-byte-pos = 1*DIGIT first-byte-pos = 1*DIGIT
instance-length = 1*DIGIT instance-length = 1*DIGIT
last-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT
other-content-range-spec = other-range-unit SP other-range-resp-spec other-content-range-spec = other-range-unit SP other-range-resp-spec
other-range-resp-spec = *CHAR other-range-resp-spec = *CHAR
other-range-set = 1*CHAR other-range-set = 1*CHAR
skipping to change at page 21, line 28 skipping to change at page 22, line 7
D.4. Since draft-ietf-httpbis-p5-range-02 D.4. Since draft-ietf-httpbis-p5-range-02
Ongoing work on IANA Message Header Field Registration Ongoing work on IANA Message Header Field Registration
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header field registrations for o Reference RFC 3984, and update header field registrations for
headers defined in this document. headers defined in this document.
D.5. Since draft-ietf-httpbis-p5-range-03 D.5. Since draft-ietf-httpbis-p5-range-03
None.
D.6. Since draft-ietf-httpbis-p5-range-04 D.6. Since draft-ietf-httpbis-p5-range-04
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/ o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
byteranges minimum number of parts" byteranges minimum number of parts"
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
skipping to change at page 23, line 30 skipping to change at page 24, line 12
o <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't o <http://tools.ietf.org/wg/httpbis/trac/ticket/217>: "Caches can't
be required to serve ranges" be required to serve ranges"
D.14. Since draft-ietf-httpbis-p5-range-12 D.14. Since draft-ietf-httpbis-p5-range-12
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification" 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"
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
Accept-Ranges header field 8 Accept-Ranges header field 8
C C
Content-Range header field 8 Content-Range header field 8
G G
Grammar Grammar
Accept-Ranges 8 Accept-Ranges 8
Accept-Ranges-v 8
acceptable-ranges 8 acceptable-ranges 8
byte-content-range-spec 8 byte-content-range-spec 8
byte-range-resp-spec 8 byte-range-resp-spec 8
byte-range-set 11 byte-range-set 12
byte-range-spec 11 byte-range-spec 12
byte-ranges-specifier 11 byte-ranges-specifier 12
bytes-unit 5 bytes-unit 5
Content-Range 8 Content-Range 8
content-range-spec 8 content-range-spec 8
Content-Range-v 8 first-byte-pos 12
first-byte-pos 11
If-Range 11 If-Range 11
If-Range-v 11
instance-length 8 instance-length 8
last-byte-pos 11 last-byte-pos 12
other-range-unit 5 other-range-unit 5
Range 13 Range 13
range-unit 5 range-unit 5
ranges-specifier 11 ranges-specifier 12
suffix-byte-range-spec 12 suffix-byte-range-spec 12
suffix-length 12 suffix-length 12
H H
Header Fields Header Fields
Accept-Ranges 8 Accept-Ranges 8
Content-Range 8 Content-Range 8
If-Range 10 If-Range 10
Range 11 Range 11
 End of changes. 37 change blocks. 
58 lines changed or deleted 72 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/