draft-ietf-httpbis-p5-range-25.txt   draft-ietf-httpbis-p5-range-26.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: May 21, 2014 J. Reschke, Ed. Expires: August 10, 2014 J. Reschke, Ed.
greenbytes greenbytes
November 17, 2013 February 6, 2014
Hypertext Transfer Protocol (HTTP/1.1): Range Requests Hypertext Transfer Protocol (HTTP/1.1): Range Requests
draft-ietf-httpbis-p5-range-25 draft-ietf-httpbis-p5-range-26
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is a stateless application-
protocol for distributed, collaborative, hypertext information level 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 May 21, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7 2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7
2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9 4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10
4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10 4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10
4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14 4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15 4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15
5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16
5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 5.3. Header Field Registration . . . . . . . . . . . . . . . . 16
5.4. Internet Media Type Registration . . . . . . . . . . . . . 17 5.4. Internet Media Type Registration . . . . . . . . . . . . . 17
5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17 5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Denial of Service Attacks using Range . . . . . . . . . . 18 6.1. Denial of Service Attacks using Range . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Internet Media Type multipart/byteranges . . . . . . 19 Appendix A. Internet Media Type multipart/byteranges . . . . . . 20
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
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) . . . . . . . . . . . . . . . . . . . . 23 publication) . . . . . . . . . . . . . . . . . . . . 23
E.1. Since draft-ietf-httpbis-p5-range-24 . . . . . . . . . . . 23 E.1. Since draft-ietf-httpbis-p5-range-24 . . . . . . . . . . . 23
E.2. Since draft-ietf-httpbis-p5-range-25 . . . . . . . . . . . 23
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Hypertext Transfer Protocol (HTTP) clients often encounter Hypertext Transfer Protocol (HTTP) clients often encounter
interrupted data transfers as a result of canceled requests or interrupted data transfers as a result of canceled requests or
dropped connections. When a client has stored a partial dropped connections. When a client has stored a partial
representation, it is desirable to request the remainder of that representation, it is desirable to request the remainder of that
representation in a subsequent request rather than transfer the representation in a subsequent request rather than transfer the
entire representation. Likewise, devices with limited local storage entire representation. Likewise, devices with limited local storage
skipping to change at page 4, line 42 skipping to change at page 4, line 42
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].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5 of [Part1]. defined in Section 2.5 of [Part1].
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 a list extension, defined in Section 7 of
7 of [Part1]. Appendix C describes rules imported from other [Part1], that allows for compact definition of comma-separated lists
documents. Appendix D shows the collected ABNF with the list rule using a '#' operator (similar to how the '*' operator indicates
expanded. repetition). Appendix C describes rules imported from other
documents. Appendix D shows the collected grammar with all list
operators expanded to standard ABNF notation.
2. Range Units 2. Range Units
A representation can be partitioned into subranges according to A representation can be partitioned into subranges according to
various structural units, depending on the structure inherent in the various structural units, depending on the structure inherent in the
representation's media type. This "range unit" is used in the representation's media type. This "range unit" is used in the
Accept-Ranges (Section 2.3) response header field to advertise Accept-Ranges (Section 2.3) response header field to advertise
support for range requests, the Range (Section 3.1) request header support for range requests, the Range (Section 3.1) request header
field to delineate the parts of a representation that are requested, field to delineate the parts of a representation that are requested,
and the Content-Range (Section 4.2) payload header field to describe and the Content-Range (Section 4.2) payload header field to describe
which part of a representation is being transferred. which part of a representation is being transferred.
range-unit = bytes-unit / other-range-unit range-unit = bytes-unit / other-range-unit
2.1. Byte Ranges 2.1. Byte Ranges
Since representation data is transferred in payloads as a sequence of Since representation data is transferred in payloads as a sequence of
octets, a byte range is a meaningful substructure for any octets, a byte range is a meaningful substructure for any
representation transferable over HTTP (Section 3 of [Part2]). We representation transferable over HTTP (Section 3 of [Part2]). The
define the "bytes" range unit for expressing subranges of the data's "bytes" range unit is defined for expressing subranges of the data's
octet sequence. octet sequence.
bytes-unit = "bytes" bytes-unit = "bytes"
A byte range request can specify a single range of bytes, or a set of A byte range request can specify a single range of bytes, or a set of
ranges within a single representation. 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 ]
skipping to change at page 7, line 47 skipping to change at page 7, line 47
3.1. Range 3.1. Range
The "Range" header field on a GET request modifies the method The "Range" header field on a GET request modifies the method
semantics to request transfer of only one or more subranges of the semantics to request transfer of only one or more subranges of the
selected representation data, rather than the entire selected selected representation data, rather than the entire selected
representation data. 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*VCHAR
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 partial retrieval of large representations. A server transfers and partial retrieval of large representations. A server
MUST ignore a Range header field received with a request method other MUST ignore a Range header field received with a request method other
than GET. than GET.
An origin server MUST ignore a Range header field that contains a An origin server MUST ignore a Range header field that contains a
range unit it does not understand. A proxy MAY discard a Range range unit it does not understand. A proxy MAY discard a Range
skipping to change at page 9, line 39 skipping to change at page 9, line 39
A client MUST NOT generate an If-Range header field containing an A client MUST NOT generate an If-Range header field containing an
entity-tag that is marked as weak. A client MUST NOT generate an If- entity-tag that is marked as weak. A client MUST NOT generate an If-
Range header field containing an HTTP-date unless the client has no Range header field containing an HTTP-date unless the client has no
entity-tag for the corresponding representation and the date is a entity-tag for the corresponding representation and the date is a
strong validator in the sense defined by Section 2.2.2 of [Part4]. strong validator in the sense defined by Section 2.2.2 of [Part4].
A server that evaluates an If-Range precondition MUST use the strong A server that evaluates an If-Range precondition MUST use the strong
comparison function when comparing entity-tags (Section 2.3.2 of comparison function when comparing entity-tags (Section 2.3.2 of
[Part4]) and MUST evaluate the condition as false if an HTTP-date [Part4]) and MUST evaluate the condition as false if an HTTP-date
validator is provided that is not a strong validator in the sense validator is provided that is not a strong validator in the sense
defined by Section 2.2.2 of [Part4]. (A server can distinguish defined by Section 2.2.2 of [Part4]. A valid entity-tag can be
between a valid HTTP-date and any form of entity-tag by examining the distinguished from a valid HTTP-date by examining the first two
first two characters.) characters for a DQUOTE.
If the validator given in the If-Range header field matches the If the validator given in the If-Range header field matches the
current validator for the selected representation of the target current validator for the selected representation of the target
resource, then the server SHOULD process the Range header field as resource, then the server SHOULD process the Range header field as
requested. If the validator does not match, the server MUST ignore requested. If the validator does not match, the server MUST ignore
the Range header field. the Range header field. Note that this comparison by exact match,
including when the validator is an HTTP-date, differs from the
"earlier than or equal to" comparison used when evaluating an If-
Unmodified-Since conditional.
4. Responses to a Range Request 4. Responses to a Range Request
4.1. 206 Partial Content 4.1. 206 Partial Content
The 206 (Partial Content) status code indicates that the server is The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that transferring one or more parts of the selected representation that
correspond to the satisfiable ranges found in the request's Range correspond to the satisfiable ranges found in the request's Range
header field (Section 3.1). header field (Section 3.1).
If a single part is being transferred, the server generating the 206 If a single part is being transferred, the server generating the 206
response MUST generate a Content-Range header field, describing what response MUST generate a Content-Range header field, describing what
skipping to change at page 17, line 33 skipping to change at page 17, line 33
"multipart/byteranges". The following is to be registered with IANA. "multipart/byteranges". The following is to be registered with IANA.
5.4.1. Internet Media Type multipart/byteranges 5.4.1. Internet Media Type multipart/byteranges
Type name: multipart Type name: multipart
Subtype name: byteranges Subtype name: byteranges
Required parameters: boundary Required parameters: boundary
Optional parameters: none Optional parameters: N/A
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: none Security considerations: see Section 6
Interoperability considerations: none Interoperability considerations: N/A
Published specification: This specification (see Appendix A). Published specification: This specification (see Appendix A).
Applications that use this media type: HTTP components supporting Applications that use this media type: HTTP components supporting
multiple ranges in a single request. multiple ranges in a single request.
Fragment identifier considerations: N/A
Additional information: Additional information:
Magic number(s): none Deprecated alias names for this type: N/A
File extension(s): none
Macintosh file type code(s): none Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Person and email address to contact for further information: See
Authors Section. Authors Section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: N/A
Author: See Authors Section. Author: See Authors Section.
Change controller: IESG Change controller: IESG
6. Security Considerations 6. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns specific to the HTTP/1.1 range and users of known security concerns specific to the HTTP range
request mechanisms. More general security considerations are request mechanisms. More general security considerations are
addressed in HTTP messaging [Part1] and semantics [Part2]. addressed in HTTP messaging [Part1] and semantics [Part2].
6.1. Denial of Service Attacks using Range 6.1. Denial of Service Attacks using Range
Unconstrained multiple range requests are susceptible to denial of Unconstrained multiple range requests are susceptible to denial of
service attacks because the effort required to request many service attacks because the effort required to request many
overlapping ranges of the same data is tiny compared to the time, overlapping ranges of the same data is tiny compared to the time,
memory, and bandwidth consumed by attempting to serve the requested memory, and bandwidth consumed by attempting to serve the requested
data in many parts. Servers ought to ignore, coalesce, or reject data in many parts. Servers ought to ignore, coalesce, or reject
skipping to change at page 18, line 44 skipping to change at page 19, line 4
overlapping ranges or for many small ranges in a single set, overlapping ranges or for many small ranges in a single set,
particularly when the ranges are requested out of order for no particularly when the ranges are requested out of order for no
apparent reason. Multipart range requests are not designed to apparent reason. Multipart range requests are not designed to
support random access. support random access.
7. Acknowledgments 7. Acknowledgments
See Section 10 of [Part1]. See Section 10 of [Part1].
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-25 (work in progress), draft-ietf-httpbis-p1-messaging-26 (work in progress),
November 2013. February 2014.
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-25 (work in progress), draft-ietf-httpbis-p2-semantics-26 (work in progress),
November 2013. February 2014.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-25 (work in progress), draft-ietf-httpbis-p4-conditional-26 (work in progress),
November 2013. February 2014.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-25 (work in progress), draft-ietf-httpbis-p6-cache-26 (work in progress),
November 2013. February 2014.
[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 22, line 41 skipping to change at page 22, line 41
complete-length = 1*DIGIT complete-length = 1*DIGIT
entity-tag = <entity-tag, defined in [Part4], Section 2.3> entity-tag = <entity-tag, defined in [Part4], Section 2.3>
first-byte-pos = 1*DIGIT first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT last-byte-pos = 1*DIGIT
other-content-range = other-range-unit SP other-range-resp other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR other-range-resp = *CHAR
other-range-set = 1*CHAR other-range-set = 1*VCHAR
other-range-unit = token other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set other-ranges-specifier = other-range-unit "=" other-range-set
range-unit = bytes-unit / other-range-unit range-unit = bytes-unit / other-range-unit
suffix-byte-range-spec = "-" suffix-length suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
token = <token, defined in [Part1], Section 3.2.6> token = <token, defined in [Part1], Section 3.2.6>
skipping to change at page 23, line 23 skipping to change at page 23, line 23
o <http://tools.ietf.org/wg/httpbis/trac/ticket/506>: "APPSDIR o <http://tools.ietf.org/wg/httpbis/trac/ticket/506>: "APPSDIR
review of draft-ietf-httpbis-p5-range-24" review of draft-ietf-httpbis-p5-range-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value
parsing" parsing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/508>: "broken o <http://tools.ietf.org/wg/httpbis/trac/ticket/508>: "broken
sentence in description of 206" sentence in description of 206"
E.2. Since draft-ietf-httpbis-p5-range-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/526>: "check media
type registration templates"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/527>: "use of CHAR
for other-range-set"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
Index Index
2 2
206 Partial Content (status code) 10 206 Partial Content (status code) 10
4 4
416 Range Not Satisfiable (status code) 15 416 Range Not Satisfiable (status code) 15
A A
Accept-Ranges header field 7 Accept-Ranges header field 7
skipping to change at page 24, line 19 skipping to change at page 24, line 39
ranges-specifier 5 ranges-specifier 5
suffix-byte-range-spec 6 suffix-byte-range-spec 6
suffix-length 6 suffix-length 6
unsatisfied-range 12 unsatisfied-range 12
I I
If-Range header field 9 If-Range header field 9
M M
Media Type Media Type
multipart/byteranges 17, 19 multipart/byteranges 17, 20
multipart/x-byteranges 20 multipart/x-byteranges 20
multipart/byteranges Media Type 17, 19 multipart/byteranges Media Type 17, 20
multipart/x-byteranges Media Type 20 multipart/x-byteranges Media Type 20
R R
Range header field 7 Range header field 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
 End of changes. 34 change blocks. 
44 lines changed or deleted 74 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/