draft-ietf-httpbis-p5-range-24.txt   draft-ietf-httpbis-p5-range-25.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: March 29, 2014 J. Reschke, Ed. Expires: May 21, 2014 J. Reschke, Ed.
greenbytes greenbytes
September 25, 2013 November 17, 2013
Hypertext Transfer Protocol (HTTP/1.1): Range Requests Hypertext Transfer Protocol (HTTP/1.1): Range Requests
draft-ietf-httpbis-p5-range-24 draft-ietf-httpbis-p5-range-25
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. This document defines range requests and the rules for systems. This document defines range requests and the rules for
constructing and combining responses to those requests. constructing and combining responses to those requests.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.5. The changes in this draft are summarized in Appendix E.1.
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 March 29, 2014. This Internet-Draft will expire on May 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 28 skipping to change at page 3, line 28
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
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5.4. Internet Media Type Registration . . . . . . . . . . . . . 17
6.1. Denial of Service Attacks using Range . . . . . . . . . . 17 5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Denial of Service Attacks using Range . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Internet Media Type multipart/byteranges . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Internet Media Type multipart/byteranges . . . . . . 19
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
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-19 . . . . . . . . . . . 23 E.1. Since draft-ietf-httpbis-p5-range-24 . . . . . . . . . . . 23
E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23
E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24
E.5. Since draft-ietf-httpbis-p5-range-23 . . . . . . . . . . . 24
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
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
might benefit from being able to request only a subset of a larger might benefit from being able to request only a subset of a larger
skipping to change at page 6, line 45 skipping to change at page 6, line 45
bytes=500-700,601-999 bytes=500-700,601-999
If a valid byte-range-set includes at least one byte-range-spec with If a valid byte-range-set includes at least one byte-range-spec with
a first-byte-pos that is less than the current length of the a first-byte-pos that is less than the current length of the
representation, or at least one suffix-byte-range-spec with a non- representation, or at least one suffix-byte-range-spec with a non-
zero suffix-length, then the byte-range-set is satisfiable. zero suffix-length, then the byte-range-set is satisfiable.
Otherwise, the byte-range-set is unsatisfiable. Otherwise, the byte-range-set is unsatisfiable.
In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-
length are expressed as decimal number of octets. Since there is no length are expressed as decimal number of octets. Since there is no
predefined limit to the length of a payload, recipients ought to predefined limit to the length of a payload, recipients MUST
anticipate potentially large decimal numerals and prevent parsing anticipate potentially large decimal numerals and prevent parsing
errors due to integer conversion overflows. errors due to integer conversion overflows.
2.2. Other Range Units 2.2. Other Range Units
Range units are intended to be extensible. New range units ought to Range units are intended to be extensible. New range units ought to
be registered with IANA, as defined in Section 5.1. be registered with IANA, as defined in Section 5.1.
other-range-unit = token other-range-unit = token
skipping to change at page 7, line 30 skipping to change at page 7, line 30
An origin server that supports byte-range requests for a given target An origin server that supports byte-range requests for a given target
resource MAY send resource MAY send
Accept-Ranges: bytes Accept-Ranges: bytes
to indicate what range units are supported. A client MAY generate to indicate what range units are supported. A client MAY generate
range requests without having received this header field for the range requests without having received this header field for the
resource involved. Range units are defined in Section 2. resource involved. Range units are defined in Section 2.
A server that does not support any kind of range request for the A server that does not support any kind of range request for the
target resource resource MAY send target resource MAY send
Accept-Ranges: none Accept-Ranges: none
to advise the client not to attempt a range request. to advise the client not to attempt a range request.
3. Range Requests 3. Range Requests
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
skipping to change at page 11, line 24 skipping to change at page 11, line 24
...the first range... ...the first range...
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-Type: application/pdf Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000 Content-Range: bytes 7000-7999/8000
...the second range ...the second range
--THIS_STRING_SEPARATES-- --THIS_STRING_SEPARATES--
When multiple ranges are requested, a server MAY coalesce any of the When multiple ranges are requested, a server MAY coalesce any of the
ranges that overlap or that are separated by a gap that is smaller ranges that overlap, or that are separated by a gap that is smaller
than the overhead of sending multiple parts, regardless of the order than the overhead of sending multiple parts, regardless of the order
in which the corresponding byte-range-spec appeared in the received in which the corresponding byte-range-spec appeared in the received
Range header field. Since the typical overhead between parts of a Range header field. Since the typical overhead between parts of a
multipart/byteranges payload is around 80 bytes, depending on the multipart/byteranges payload is around 80 bytes, depending on the
selected representation's media type and the chosen boundary selected representation's media type and the chosen boundary
parameter length, it can be less efficient to transfer many small parameter length, it can be less efficient to transfer many small
disjoint parts than it is to transfer the entire selected disjoint parts than it is to transfer the entire selected
representation. representation.
A server MUST NOT generate a multipart response to a request for a A server MUST NOT generate a multipart response to a request for a
skipping to change at page 12, line 19 skipping to change at page 12, line 19
Vary. Vary.
If a 206 is generated in response to a request with an If-Range If a 206 is generated in response to a request with an If-Range
header field, the sender SHOULD NOT generate other representation header field, the sender SHOULD NOT generate other representation
header fields beyond those required above, because the client is header fields beyond those required above, because the client is
understood to already have a prior response containing those header understood to already have a prior response containing those header
fields. Otherwise, the sender MUST generate all of the fields. Otherwise, the sender MUST generate all of the
representation header fields that would have been sent in a 200 (OK) representation header fields that would have been sent in a 200 (OK)
response to the same request. response to the same request.
A 206 response is cacheable unless otherwise indicated by explicit A 206 response is cacheable by default; i.e., unless otherwise
cache controls (see Section 4.2.2 of [Part6]). indicated by explicit cache controls (see Section 4.2.2 of [Part6]).
4.2. Content-Range 4.2. Content-Range
The "Content-Range" header field is sent in a single part 206 The "Content-Range" header field is sent in a single part 206
(Partial Content) response to indicate the partial range of the (Partial Content) response to indicate the partial range of the
selected representation enclosed as the message payload, sent in each selected representation enclosed as the message payload, sent in each
part of a multipart 206 response to indicate the range enclosed part of a multipart 206 response to indicate the range enclosed
within each body part, and sent in 416 (Range Not Satisfiable) within each body part, and sent in 416 (Range Not Satisfiable)
responses to provide information about the selected representation. responses to provide information about the selected representation.
skipping to change at page 15, line 42 skipping to change at page 15, line 42
received a complete representation. Thus, clients cannot depend received a complete representation. Thus, clients cannot depend
on receiving a 416 (Range Not Satisfiable) response even when it on receiving a 416 (Range Not Satisfiable) response even when it
is most appropriate. is most appropriate.
5. IANA Considerations 5. IANA Considerations
5.1. Range Unit Registry 5.1. Range Unit Registry
The HTTP Range Unit Registry defines the name space for the range The HTTP Range Unit Registry defines the name space for the range
unit names and refers to their corresponding specifications. The unit names and refers to their corresponding specifications. The
registry will be created and maintained at registry will be created and maintained at (the suggested URI)
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
5.1.1. Procedure 5.1.1. Procedure
Registration of an HTTP Range Unit MUST include the following fields: Registration of an HTTP Range Unit 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 17, line 17 skipping to change at page 17, line 17
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Accept-Ranges | http | standard | Section 2.3 | | Accept-Ranges | http | standard | Section 2.3 |
| Content-Range | http | standard | Section 4.2 | | Content-Range | http | standard | Section 4.2 |
| If-Range | http | standard | Section 3.2 | | If-Range | http | standard | Section 3.2 |
| Range | http | standard | Section 3.1 | | Range | http | standard | Section 3.1 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
5.4. Internet Media Type Registration
IANA maintains the registry of Internet media types [BCP13] at
<http://www.iana.org/assignments/media-types>.
This document serves as the specification for the Internet media type
"multipart/byteranges". The following is to be registered with IANA.
5.4.1. Internet Media Type multipart/byteranges
Type name: multipart
Subtype name: byteranges
Required parameters: boundary
Optional parameters: none
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Interoperability considerations: none
Published specification: This specification (see Appendix A).
Applications that use this media type: HTTP components supporting
multiple ranges in a single request.
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author: See Authors Section.
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/1.1 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
skipping to change at page 17, line 47 skipping to change at page 18, line 49
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-24 (work in progress), draft-ietf-httpbis-p1-messaging-25 (work in progress),
September 2013. November 2013.
[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-24 (work in progress), draft-ietf-httpbis-p2-semantics-25 (work in progress),
September 2013. November 2013.
[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-24 (work in progress), draft-ietf-httpbis-p4-conditional-25 (work in progress),
September 2013. November 2013.
[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-24 (work in progress), draft-ietf-httpbis-p6-cache-25 (work in progress),
September 2013. November 2013.
[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 18, line 49 skipping to change at page 20, line 4
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
Appendix A. Internet Media Type multipart/byteranges Appendix A. Internet Media Type multipart/byteranges
When a 206 (Partial Content) response message includes the content of When a 206 (Partial Content) response message includes the content of
multiple ranges, they are transmitted as body parts in a multipart multiple ranges, they are transmitted as body parts in a multipart
message body ([RFC2046], Section 5.1) with the media type of message body ([RFC2046], Section 5.1) with the media type of
"multipart/byteranges". The following definition is to be registered "multipart/byteranges".
with IANA [BCP13].
The multipart/byteranges media type includes one or more body parts, The multipart/byteranges media type includes one or more body parts,
each with its own Content-Type and Content-Range fields. The each with its own Content-Type and Content-Range fields. The
required boundary parameter specifies the boundary string used to required boundary parameter specifies the boundary string used to
separate each body part. separate each body part.
Type name: multipart
Subtype name: byteranges
Required parameters: boundary
Optional parameters: none
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Interoperability considerations: none
Published specification: This specification (see Appendix A).
Applications that use this media type: HTTP components supporting
multiple ranges in a single request.
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author: See Authors Section.
Change controller: IESG
Implementation Notes: Implementation Notes:
1. Additional CRLFs might precede the first boundary string in the 1. Additional CRLFs might precede the first boundary string in the
body. body.
2. Although [RFC2046] permits the boundary string to be quoted, some 2. Although [RFC2046] permits the boundary string to be quoted, some
existing implementations handle a quoted boundary string existing implementations handle a quoted boundary string
incorrectly. incorrectly.
3. A number of clients and servers were coded to an early draft of 3. A number of clients and servers were coded to an early draft of
skipping to change at page 23, line 7 skipping to change at page 23, line 7
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>
unsatisfied-range = "*/" complete-length unsatisfied-range = "*/" complete-length
Appendix E. Change Log (to be removed by RFC Editor before publication) Appendix E. Change Log (to be removed by RFC Editor before publication)
Changes up to the first Working Group Last Call draft are summarized Changes up to the IETF Last Call draft are summarized in <http://
in <http://tools.ietf.org/html/ tools.ietf.org/html/draft-ietf-httpbis-p5-range-24#appendix-E>.
draft-ietf-httpbis-p5-range-19#appendix-D>.
E.1. Since draft-ietf-httpbis-p5-range-19
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/358>: "ABNF list
expansion code problem"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
requirements for recipients"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve
'none' as byte range unit"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
introduction of new IANA registries as normative changes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units
vs leading zeroes vs size"
E.2. Since draft-ietf-httpbis-p5-range-20
o Conformance criteria and considerations regarding error handling
are now defined in Part 1.
E.3. Since draft-ietf-httpbis-p5-range-21
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
consideration: range flooding"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
heuristic caching for new status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
limitations to Range to reduce its use as a denial-of-service
tool"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/407>: "416 and
multipart/byteranges"
E.4. Since draft-ietf-httpbis-p5-range-22 E.1. Since draft-ietf-httpbis-p5-range-24
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list o <http://tools.ietf.org/wg/httpbis/trac/ticket/506>: "APPSDIR
expansion in ABNF appendices" review of draft-ietf-httpbis-p5-range-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/437>: "incorrect
example dates"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type
registration template issues"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/462>: "Editorial
suggestions"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/485>: "MUSTs and
other feedback"
E.5. Since draft-ietf-httpbis-p5-range-23
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/489>: "is P5's o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value
definition of strong validator consistent with P4?" parsing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/490>: "p5 editorial o <http://tools.ietf.org/wg/httpbis/trac/ticket/508>: "broken
comments" sentence in description of 206"
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
skipping to change at page 25, line 30 skipping to change at page 24, line 19
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 18 multipart/byteranges 17, 19
multipart/x-byteranges 20 multipart/x-byteranges 20
multipart/byteranges Media Type 18 multipart/byteranges Media Type 17, 19
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. 26 change blocks. 
142 lines changed or deleted 90 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/