p5-range.unpg.txt   rfc7233.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7233 Adobe
Obsoletes: 2616 (if approved) Y. Lafon, Ed. Obsoletes: 2616 Y. Lafon, Ed.
Intended status: Standards Track W3C Category: Standards Track W3C
Expires: December 8, 2014 J. Reschke, Ed. ISSN: 2070-1721 J. Reschke, Ed.
greenbytes greenbytes
June 6, 2014 June 2014
Hypertext Transfer Protocol (HTTP/1.1): Range Requests Hypertext Transfer Protocol (HTTP/1.1): Range Requests
draft-ietf-httpbis-p5-range-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level 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)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<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
<http://tools.ietf.org/wg/httpbis/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7233.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 .....................................................5
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 ..................................................8
3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Range ......................................................8
3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. If-Range ...................................................9
4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10 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 ............................................16
5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15 5.1. Range Unit Registry .......................................16
5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Procedure ..........................................16
5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Registrations ......................................16
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16 5.2. Status Code Registration ..................................17
5.3. Header Field Registration . . . . . . . . . . . . . . . . 16 5.3. Header Field Registration .................................17
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 ...........18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations ........................................19
6.1. Denial-of-Service Attacks Using Range . . . . . . . . . . 18 6.1. Denial-of-Service Attacks Using Range .....................19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments ................................................19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References .....................................................20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References ......................................20
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References ....................................20
Appendix A. Internet Media Type multipart/byteranges . . . . . . 20 Appendix A. Internet Media Type multipart/byteranges ..............21
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 Appendix B. Changes from RFC 2616 .................................22
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Imported ABNF .........................................22
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21 Appendix D. Collected ABNF ........................................23
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 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 16 skipping to change at page 6, line 22
the remainder of the representation (i.e., the server replaces the the remainder of the representation (i.e., the server replaces the
value of last-byte-pos with a value that is one less than the current value of last-byte-pos with a value that is one less than the current
length of the selected representation). length of the selected representation).
A client can request the last N bytes of the selected representation A client can request the last N bytes of the selected representation
using a suffix-byte-range-spec. using a suffix-byte-range-spec.
suffix-byte-range-spec = "-" suffix-length suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT suffix-length = 1*DIGIT
If the selected representation is shorter than the specified suffix- If the selected representation is shorter than the specified
length, the entire representation is used. suffix-length, the entire representation is used.
Additional examples, assuming a representation of length 10000: Additional examples, assuming a representation of length 10000:
o The final 500 bytes (byte offsets 9500-9999, inclusive): o The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500 bytes=-500
Or: Or:
bytes=9500- bytes=9500-
o The first and last bytes only (bytes 0 and 9999): o The first and last bytes only (bytes 0 and 9999):
bytes=0-0,-1 bytes=0-0,-1
o Other valid (but not canonical) specifications of the second 500 o Other valid (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
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
zero suffix-length, then the byte-range-set is satisfiable. non-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
length are expressed as decimal number of octets. Since there is no suffix-length are expressed as decimal number of octets. Since there
predefined limit to the length of a payload, recipients MUST is no 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 9, line 23 skipping to change at page 9, line 38
representation. 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 as follows: if the second request. Informally, its meaning is as follows: if the
representation is unchanged, send me the part(s) that I am requesting representation is unchanged, send me the part(s) that I am requesting
in Range; otherwise, send me the entire representation. in Range; otherwise, send me the entire representation.
If-Range = entity-tag / HTTP-date If-Range = entity-tag / HTTP-date
A client MUST NOT generate an If-Range header field in a request that A client MUST NOT generate an If-Range header field in a request that
does not contain a Range header field. A server MUST ignore an If- does not contain a Range header field. A server MUST ignore an
Range header field received in a request that does not contain a If-Range header field received in a request that does not contain a
Range header field. An origin server MUST ignore an If-Range header Range header field. An origin server MUST ignore an If-Range header
field received in a request for a target resource that does not field received in a request for a target resource that does not
support Range requests. support Range requests.
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
Range header field containing an HTTP-date unless the client has no If-Range header field containing an HTTP-date unless the client has
entity-tag for the corresponding representation and the date is a no entity-tag for the corresponding representation and the date is a
strong validator in the sense defined by Section 2.2.2 of [RFC7232]. strong validator in the sense defined by Section 2.2.2 of [RFC7232].
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
[RFC7232]) and MUST evaluate the condition as false if an HTTP-date [RFC7232]) 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 [RFC7232]. A valid entity-tag can be defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be
distinguished from a valid HTTP-date by examining the first two distinguished from a valid HTTP-date by examining the first two
characters for a DQUOTE. 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. Note that this comparison by exact match, the Range header field. Note that this comparison by exact match,
including when the validator is an HTTP-date, differs from the including when the validator is an HTTP-date, differs from the
"earlier than or equal to" comparison used when evaluating an If- "earlier than or equal to" comparison used when evaluating an
Unmodified-Since conditional. 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).
skipping to change at page 11, line 44 skipping to change at page 11, line 51
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
single range, since a client that does not request multiple parts single range, since a client that does not request multiple parts
might not support multipart responses. However, a server MAY might not support multipart responses. However, a server MAY
generate a multipart/byteranges payload with only a single body part generate a multipart/byteranges payload with only a single body part
if multiple ranges were requested and only one range was found to be if multiple ranges were requested and only one range was found to be
satisfiable or only one range remained after coalescing. A client satisfiable or only one range remained after coalescing. A client
that cannot process a multipart/byteranges response MUST NOT generate that cannot process a multipart/byteranges response MUST NOT generate
a request that asks for multiple ranges. a request that asks for multiple ranges.
When a multipart response payload is generated, the server SHOULD When a multipart response payload is generated, the server SHOULD
send the parts in the same order that the corresponding byte-range- send the parts in the same order that the corresponding
spec appeared in the received Range header field, excluding those byte-range-spec appeared in the received Range header field,
ranges that were deemed unsatisfiable or that were coalesced into excluding those ranges that were deemed unsatisfiable or that were
other ranges. A client that receives a multipart response MUST coalesced into other ranges. A client that receives a multipart
inspect the Content-Range header field present in each body part in response MUST inspect the Content-Range header field present in each
order to determine which range is contained in that body part; a body part in order to determine which range is contained in that body
client cannot rely on receiving the same ranges that it requested, part; a client cannot rely on receiving the same ranges that it
nor the same order that it requested. requested, nor the same order that it requested.
When a 206 response is generated, the server MUST generate the When a 206 response is generated, the server MUST generate the
following header fields, in addition to those required above, if the following header fields, in addition to those required above, if the
field would have been sent in a 200 (OK) response to the same field would have been sent in a 200 (OK) response to the same
request: Date, Cache-Control, ETag, Expires, Content-Location, and request: Date, Cache-Control, ETag, Expires, Content-Location, and
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
skipping to change at page 13, line 22 skipping to change at page 13, line 28
The following example illustrates when the complete length of the The following example illustrates when the complete length of the
selected representation is known by the sender to be 1234 bytes: selected representation is known by the sender to be 1234 bytes:
Content-Range: bytes 42-1233/1234 Content-Range: bytes 42-1233/1234
and this second example illustrates when the complete length is and this second example illustrates when the complete length is
unknown: unknown:
Content-Range: bytes 42-1233/* Content-Range: bytes 42-1233/*
A Content-Range field value is invalid if it contains a byte-range- A Content-Range field value is invalid if it contains a
resp that has a last-byte-pos value less than its first-byte-pos byte-range-resp that has a last-byte-pos value less than its
value, or a complete-length value less than or equal to its last- first-byte-pos value, or a complete-length value less than or equal
byte-pos value. The recipient of an invalid Content-Range MUST NOT to its last-byte-pos value. The recipient of an invalid
attempt to recombine the received content with a stored Content-Range MUST NOT attempt to recombine the received content with
representation. a stored representation.
A server generating a 416 (Range Not Satisfiable) response to a byte- A server generating a 416 (Range Not Satisfiable) response to a
range request SHOULD send a Content-Range header field with an byte-range request SHOULD send a Content-Range header field with an
unsatisfied-range value, as in the following example: unsatisfied-range value, as in the following example:
Content-Range: bytes */1234 Content-Range: bytes */1234
The complete-length in a 416 response indicates the current length of The complete-length in a 416 response indicates the current length of
the selected representation. the selected representation.
The Content-Range header field has no meaning for status codes that The Content-Range header field has no meaning for status codes that
do not explicitly describe its semantic. For this specification, do not explicitly describe its semantic. For this specification,
only the 206 (Partial Content) and 416 (Range Not Satisfiable) status only the 206 (Partial Content) and 416 (Range Not Satisfiable) status
skipping to change at page 19, line 18 skipping to change at page 20, line 21
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.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] 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-latest (work in progress), RFC 7230, June 2014.
June 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
draft-ietf-httpbis-p2-semantics-latest (work in progress),
June 2014. June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
draft-ietf-httpbis-p4-conditional-latest (work in June 2014.
progress), June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] 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-latest (work in progress), RFC 7234, June 2014.
June 2014.
8.2. Informative References 8.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
skipping to change at page 21, line 30 skipping to change at page 22, line 29
Appendix C. Imported ABNF Appendix C. Imported ABNF
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character). character).
Note that all rules derived from token are to be compared case- Note that all rules derived from token are to be compared
insensitively, like range-unit and acceptable-ranges. case-insensitively, like range-unit and acceptable-ranges.
The rules below are defined in [RFC7230]: The rules below are defined in [RFC7230]:
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, see [RFC7230], Section 3.2.3>
token = <token, see [RFC7230], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6>
The rules below are defined in other parts: The rules below are defined in other parts:
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
entity-tag = <entity-tag, see [RFC7232], Section 2.3> entity-tag = <entity-tag, see [RFC7232], Section 2.3>
skipping to change at page 23, line 38 skipping to change at page 24, line 43
byte-ranges-specifier 5 byte-ranges-specifier 5
bytes-unit 5 bytes-unit 5
complete-length 12 complete-length 12
Content-Range 12 Content-Range 12
first-byte-pos 5 first-byte-pos 5
If-Range 9 If-Range 9
last-byte-pos 5 last-byte-pos 5
other-content-range 12 other-content-range 12
other-range-resp 12 other-range-resp 12
other-range-unit 5, 7 other-range-unit 5, 7
Range 7 Range 8
range-unit 5 range-unit 5
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, 20 multipart/byteranges 18, 21
multipart/x-byteranges 20 multipart/x-byteranges 19
multipart/byteranges Media Type 17, 20 multipart/byteranges Media Type 18, 21
multipart/x-byteranges Media Type 20 multipart/x-byteranges Media Type 21
R R
Range header field 7 Range header field 8
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 26 change blocks. 
114 lines changed or deleted 93 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/