draft-ietf-httpbis-p5-range-12.txt   draft-ietf-httpbis-p5-range-13.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software 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: April 28, 2011 J. Mogul Expires: September 15, 2011 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems 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
October 25, 2010 March 14, 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-12 draft-ietf-httpbis-p5-range-13
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). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related 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.13. The changes in this draft are summarized in Appendix D.14.
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 April 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 46 skipping to change at page 3, line 46
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 . . . . . . . . . . . 21
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 21
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21
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 . . . . . . . . . . . 22
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 22
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 22
D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 22 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 22
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
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
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
skipping to change at page 7, line 13 skipping to change at page 7, line 13
exactly, see Section 4. exactly, see Section 4.
A cache that does not support the Range and Content-Range header A cache that does not support the Range and Content-Range header
fields MUST NOT cache 206 (Partial Content) responses. Furthermore, fields MUST NOT cache 206 (Partial Content) responses. Furthermore,
if a response uses a range unit that is not understood by the cache, if a response uses a range unit that is not understood by the cache,
then it MUST NOT be cached either. then it MUST NOT be cached either.
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 request-header field (Section 5.4), and none of the included a Range header field (Section 5.4), and none of the ranges-
ranges-specifier values in this field overlap the current extent of specifier values in this field overlap the current extent of the
the selected resource, and the request did not include an If-Range selected resource, and the request did not include an If-Range header
request-header field (Section 5.3). (For byte-ranges, this means field (Section 5.3). (For byte-ranges, this means that the first-
that the first-byte-pos of all of the byte-range-spec values were byte-pos of all of the byte-range-spec values were greater than the
greater than the current length of the selected resource.) current length of the selected resource.)
When this status code is returned for a byte-range request, the When this status code is returned for a byte-range request, the
response SHOULD include a Content-Range header field specifying the response SHOULD include a Content-Range header field specifying the
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. response MUST NOT use the multipart/byteranges content-type.
4. Combining Ranges 4. Combining Ranges
A response might transfer only a subrange of a representation, either A response might transfer only a subrange of a representation, either
because the request included one or more Range specifications, or because the request included one or more Range specifications, or
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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" response-header field allows a resource to The "Accept-Ranges" header field allows a resource to indicate its
indicate its acceptance of range requests. acceptance of range requests.
Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v
Accept-Ranges-v = 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
skipping to change at page 10, line 36 skipping to change at page 10, line 36
When a client requests multiple ranges in one request, the server When a client requests 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.
If the server ignores a byte-range-spec because it is syntactically If the server ignores a byte-range-spec because it is syntactically
invalid, the server SHOULD treat the request as if the invalid Range invalid, 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
response containing the full representation). response containing the full representation).
If the server receives a request (other than one including an If- If the server receives a request (other than one including an If-
Range request-header field) with an unsatisfiable Range request- Range header field) with an unsatisfiable Range header field (that
header field (that is, all of whose byte-range-spec values have a is, all of whose byte-range-spec values have a first-byte-pos value
first-byte-pos value greater than the current length of the selected greater than the current length of the selected resource), it SHOULD
resource), it SHOULD return a response code of 416 (Requested range return a response code of 416 (Requested range not satisfiable)
not satisfiable) (Section 3.2). (Section 3.2).
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 request-header field, since not all servers an unsatisfiable Range header field, since not all servers
implement this request-header field. implement this header field.
5.3. If-Range 5.3. If-Range
If a client has a partial copy of a representation in its cache, and If a client has a partial copy of a representation in its cache, and
wishes to have an up-to-date copy of the entire representation in its wishes to have an up-to-date copy of the entire representation in its
cache, it could use the Range request-header field with a conditional cache, it could use the Range header field with a conditional GET
GET (using either or both of If-Unmodified-Since and If-Match.) (using either or both of If-Unmodified-Since and If-Match.) However,
However, if the condition fails because the representation has been if the condition fails because the representation has been modified,
modified, the client would then have to make a second request to the client would then have to make a second request to obtain the
obtain the entire current representation. entire current representation.
The "If-Range" request-header field allows a client to "short- The "If-Range" header field allows a client to "short-circuit" the
circuit" the second request. Informally, its meaning is "if the second request. Informally, its meaning is "if the representation is
representation is unchanged, send me the part(s) that I am missing; unchanged, send me the part(s) that I am missing; otherwise, send me
otherwise, send me the entire new representation". the entire new representation".
If-Range = "If-Range" ":" OWS If-Range-v If-Range = "If-Range" ":" OWS If-Range-v
If-Range-v = entity-tag / HTTP-date If-Range-v = entity-tag / HTTP-date
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
skipping to change at page 13, line 29 skipping to change at page 13, line 29
bytes=0-0,-1 bytes=0-0,-1
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" request-header field defines the GET method (conditional The "Range" header field defines the GET method (conditional or not)
or not) to request one or more sub-ranges of the response to request one or more sub-ranges of the response representation
representation body, instead of the entire representation body. body, instead of the entire representation body.
Range = "Range" ":" OWS Range-v Range = "Range" ":" OWS Range-v
Range-v = byte-ranges-specifier Range-v = byte-ranges-specifier
/ other-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
skipping to change at page 15, line 44 skipping to change at page 15, line 44
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-12 and Message Parsing", draft-ietf-httpbis-p1-messaging-13
(work in progress), October 2010. (work in progress), March 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-12 (work in Requests", draft-ietf-httpbis-p4-conditional-13 (work in
progress), October 2010. progress), March 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 23, line 23 skipping to change at page 23, line 23
o Add IANA registry. o Add IANA registry.
D.13. Since draft-ietf-httpbis-p5-range-11 D.13. Since draft-ietf-httpbis-p5-range-11
Closed issues: Closed issues:
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
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification"
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 8 Accept-Ranges header field 8
C C
Content-Range header 8 Content-Range header field 8
G G
Grammar Grammar
Accept-Ranges 8 Accept-Ranges 8
Accept-Ranges-v 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 11
byte-range-spec 11 byte-range-spec 11
skipping to change at page 24, line 15 skipping to change at page 24, line 22
instance-length 8 instance-length 8
last-byte-pos 11 last-byte-pos 11
other-range-unit 5 other-range-unit 5
Range 13 Range 13
range-unit 5 range-unit 5
ranges-specifier 11 ranges-specifier 11
suffix-byte-range-spec 12 suffix-byte-range-spec 12
suffix-length 12 suffix-length 12
H H
Headers Header Fields
Accept-Ranges 8 Accept-Ranges 8
Content-Range 8 Content-Range 8
If-Range 10 If-Range 10
Range 11 Range 11
I I
If-Range header 10 If-Range header field 10
M M
Media Type Media Type
multipart/byteranges 16 multipart/byteranges 16
multipart/x-byteranges 19 multipart/x-byteranges 19
multipart/byteranges Media Type 16 multipart/byteranges Media Type 16
multipart/x-byteranges Media Type 19 multipart/x-byteranges Media Type 19
R R
Range header 11 Range header field 11
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
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Adobe Systems Incorporated
23 Corporate Plaza DR, Suite 280 345 Park Ave
Newport Beach, CA 92660 San Jose, CA 95110
USA USA
Phone: +1-949-706-5300
Fax: +1-949-706-5305
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
EMail: jg@freedesktop.org EMail: jg@freedesktop.org
URI: http://gettys.wordpress.com/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
skipping to change at page 25, line 29 skipping to change at page 26, line 4
EMail: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
EMail: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
 End of changes. 29 change blocks. 
51 lines changed or deleted 57 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/