mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-12-11 12:23:31 +00:00
1513 lines
48 KiB
Text
1513 lines
48 KiB
Text
|
|
|||
|
|
|||
|
|
|||
|
HTTPbis Working Group R. Fielding, Ed.
|
|||
|
Internet-Draft Day Software
|
|||
|
Obsoletes: 2616 (if approved) J. Gettys
|
|||
|
Intended status: Standards Track Alcatel-Lucent
|
|||
|
Expires: February 5, 2011 J. Mogul
|
|||
|
HP
|
|||
|
H. Frystyk
|
|||
|
Microsoft
|
|||
|
L. Masinter
|
|||
|
Adobe Systems
|
|||
|
P. Leach
|
|||
|
Microsoft
|
|||
|
T. Berners-Lee
|
|||
|
W3C/MIT
|
|||
|
Y. Lafon, Ed.
|
|||
|
W3C
|
|||
|
J. Reschke, Ed.
|
|||
|
greenbytes
|
|||
|
August 4, 2010
|
|||
|
|
|||
|
|
|||
|
HTTP/1.1, part 5: Range Requests and Partial Responses
|
|||
|
draft-ietf-httpbis-p5-range-11
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
The Hypertext Transfer Protocol (HTTP) is an application-level
|
|||
|
protocol for distributed, collaborative, hypermedia information
|
|||
|
systems. HTTP has been in use by the World Wide Web global
|
|||
|
information initiative since 1990. This document is Part 5 of the
|
|||
|
seven-part specification that defines the protocol referred to as
|
|||
|
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines
|
|||
|
range-specific requests and the rules for constructing and combining
|
|||
|
responses to those requests.
|
|||
|
|
|||
|
Editorial Note (To be removed by RFC Editor)
|
|||
|
|
|||
|
Discussion of this draft should take place on the HTTPBIS working
|
|||
|
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
|
|||
|
documents (including fancy diffs) can be found at
|
|||
|
<http://tools.ietf.org/wg/httpbis/>.
|
|||
|
|
|||
|
The changes in this draft are summarized in Appendix D.12.
|
|||
|
|
|||
|
Status of This Memo
|
|||
|
|
|||
|
This Internet-Draft is submitted in full conformance with the
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 1]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
provisions of BCP 78 and BCP 79.
|
|||
|
|
|||
|
Internet-Drafts are working documents of the Internet Engineering
|
|||
|
Task Force (IETF). Note that other groups may also distribute
|
|||
|
working documents as Internet-Drafts. The list of current Internet-
|
|||
|
Drafts is at http://datatracker.ietf.org/drafts/current/.
|
|||
|
|
|||
|
Internet-Drafts are draft documents valid for a maximum of six months
|
|||
|
and may be updated, replaced, or obsoleted by other documents at any
|
|||
|
time. It is inappropriate to use Internet-Drafts as reference
|
|||
|
material or to cite them other than as "work in progress."
|
|||
|
|
|||
|
This Internet-Draft will expire on February 5, 2011.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (c) 2010 IETF Trust and the persons identified as the
|
|||
|
document authors. All rights reserved.
|
|||
|
|
|||
|
This document is subject to BCP 78 and the IETF Trust's Legal
|
|||
|
Provisions Relating to IETF Documents
|
|||
|
(http://trustee.ietf.org/license-info) in effect on the date of
|
|||
|
publication of this document. Please review these documents
|
|||
|
carefully, as they describe your rights and restrictions with respect
|
|||
|
to this document. Code Components extracted from this document must
|
|||
|
include Simplified BSD License text as described in Section 4.e of
|
|||
|
the Trust Legal Provisions and are provided without warranty as
|
|||
|
described in the Simplified BSD License.
|
|||
|
|
|||
|
This document may contain material from IETF Documents or IETF
|
|||
|
Contributions published or made publicly available before November
|
|||
|
10, 2008. The person(s) controlling the copyright in some of this
|
|||
|
material may not have granted the IETF Trust the right to allow
|
|||
|
modifications of such material outside the IETF Standards Process.
|
|||
|
Without obtaining an adequate license from the person(s) controlling
|
|||
|
the copyright in such materials, this document may not be modified
|
|||
|
outside the IETF Standards Process, and derivative works of it may
|
|||
|
not be created outside the IETF Standards Process, except to format
|
|||
|
it for publication as an RFC or to translate it into languages other
|
|||
|
than English.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 2]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
|
|||
|
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
|
|||
|
1.2.2. ABNF Rules defined in other Parts of the
|
|||
|
Specification . . . . . . . . . . . . . . . . . . . . 6
|
|||
|
2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
|||
|
2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
|
|||
|
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
|
|||
|
3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
|
|||
|
3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8
|
|||
|
4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
|
|||
|
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8
|
|||
|
5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
|
|||
|
5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
|
|||
|
5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
|||
|
5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
|||
|
5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12
|
|||
|
5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14
|
|||
|
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
|
|||
|
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
|
|||
|
6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
|
|||
|
6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
|
|||
|
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
|
|||
|
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
|
|||
|
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
|
|||
|
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
|
|||
|
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
|
|||
|
Appendix A. Internet Media Type multipart/byteranges . . . . . . 17
|
|||
|
Appendix B. Compatibility with Previous Versions . . . . . . . . 20
|
|||
|
B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
|
|||
|
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
|
|||
|
Appendix D. Change Log (to be removed by RFC Editor before
|
|||
|
publication) . . . . . . . . . . . . . . . . . . . . 21
|
|||
|
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
|
|||
|
D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
|
|||
|
D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
|
|||
|
D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
|
|||
|
D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22
|
|||
|
D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22
|
|||
|
D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
|
|||
|
D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
|
|||
|
D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23
|
|||
|
D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23
|
|||
|
D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23
|
|||
|
D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 3]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 4]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
HTTP clients often encounter interrupted data transfers as a result
|
|||
|
of cancelled requests or dropped connections. When a cache has
|
|||
|
stored a partial representation, it is desirable to request the
|
|||
|
remainder of that representation in a subsequent request rather than
|
|||
|
transfer the entire representation. There are also a number of Web
|
|||
|
applications that benefit from being able to request only a subset of
|
|||
|
a larger representation, such as a single page of a very large
|
|||
|
document or only part of an image to be rendered by a device with
|
|||
|
limited local storage.
|
|||
|
|
|||
|
This document defines HTTP/1.1 range requests, partial responses, and
|
|||
|
the multipart/byteranges media type. The protocol for range requests
|
|||
|
is an OPTIONAL feature of HTTP, designed so resources or recipients
|
|||
|
that do not implement this feature can respond as if it is a normal
|
|||
|
GET request without impacting interoperability. Partial responses
|
|||
|
are indicated by a distinct status code to not be mistaken for full
|
|||
|
responses by intermediate caches that might not implement the
|
|||
|
feature.
|
|||
|
|
|||
|
Although the HTTP range request mechanism is designed to allow for
|
|||
|
extensible range types, this specification only defines requests for
|
|||
|
byte ranges.
|
|||
|
|
|||
|
1.1. Requirements
|
|||
|
|
|||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
document are to be interpreted as described in [RFC2119].
|
|||
|
|
|||
|
An implementation is not compliant if it fails to satisfy one or more
|
|||
|
of the "MUST" or "REQUIRED" level requirements for the protocols it
|
|||
|
implements. An implementation that satisfies all the "MUST" or
|
|||
|
"REQUIRED" level and all the "SHOULD" level requirements for its
|
|||
|
protocols is said to be "unconditionally compliant"; one that
|
|||
|
satisfies all the "MUST" level requirements but not all the "SHOULD"
|
|||
|
level requirements for its protocols is said to be "conditionally
|
|||
|
compliant".
|
|||
|
|
|||
|
1.2. Syntax Notation
|
|||
|
|
|||
|
This specification uses the ABNF syntax defined in Section 1.2 of
|
|||
|
[Part1] (which extends the syntax defined in [RFC5234] with a list
|
|||
|
rule). Appendix C shows the collected ABNF, with the list rule
|
|||
|
expanded.
|
|||
|
|
|||
|
The following core rules are included by reference, as defined in
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 5]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), 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 8-bit
|
|||
|
sequence of data), SP (space), VCHAR (any visible USASCII character),
|
|||
|
and WSP (whitespace).
|
|||
|
|
|||
|
1.2.1. Core Rules
|
|||
|
|
|||
|
The core rules below are defined in Section 1.2.2 of [Part1]:
|
|||
|
|
|||
|
token = <token, defined in [Part1], Section 1.2.2>
|
|||
|
OWS = <OWS, defined in [Part1], Section 1.2.2>
|
|||
|
|
|||
|
1.2.2. ABNF Rules defined in other Parts of the Specification
|
|||
|
|
|||
|
The ABNF rules below are defined in other parts:
|
|||
|
|
|||
|
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
|
|||
|
|
|||
|
|
|||
|
entity-tag = <entity-tag, defined in [Part4], Section 2>
|
|||
|
|
|||
|
2. Range Units
|
|||
|
|
|||
|
HTTP/1.1 allows a client to request that only part (a range of) the
|
|||
|
representation be included within the response. HTTP/1.1 uses range
|
|||
|
units in the Range (Section 5.4) and Content-Range (Section 5.2)
|
|||
|
header fields. A representation can be broken down into subranges
|
|||
|
according to various structural units.
|
|||
|
|
|||
|
range-unit = bytes-unit / other-range-unit
|
|||
|
bytes-unit = "bytes"
|
|||
|
other-range-unit = token
|
|||
|
|
|||
|
HTTP/1.1 has been designed to allow implementations of applications
|
|||
|
that do not depend on knowledge of ranges. The only range unit
|
|||
|
defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
|
|||
|
as described in Section 2.1.
|
|||
|
|
|||
|
If a range unit is not understood in a request, a server MUST ignore
|
|||
|
the whole Range header (Section 5.4). If a range unit is not
|
|||
|
understood in a response, an intermediary SHOULD pass the response to
|
|||
|
the client; a client MUST fail.
|
|||
|
|
|||
|
2.1. Range Specifier Registry
|
|||
|
|
|||
|
The HTTP Ranger Specifier Registry defines the name space for the
|
|||
|
range specifier names.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 6]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
Registrations MUST include the following fields:
|
|||
|
|
|||
|
o Name
|
|||
|
|
|||
|
o Description
|
|||
|
|
|||
|
o Pointer to specification text
|
|||
|
|
|||
|
Values to be added to this name space are subject to IETF review
|
|||
|
([RFC5226], Section 4.1).
|
|||
|
|
|||
|
The registry itself is maintained at
|
|||
|
<http://www.iana.org/assignments/http-range-specifiers>.
|
|||
|
|
|||
|
3. Status Code Definitions
|
|||
|
|
|||
|
3.1. 206 Partial Content
|
|||
|
|
|||
|
The server has fulfilled the partial GET request for the resource.
|
|||
|
The request MUST have included a Range header field (Section 5.4)
|
|||
|
indicating the desired range, and MAY have included an If-Range
|
|||
|
header field (Section 5.3) to make the request conditional.
|
|||
|
|
|||
|
The response MUST include the following header fields:
|
|||
|
|
|||
|
o Either a Content-Range header field (Section 5.2) indicating the
|
|||
|
range included with this response, or a multipart/byteranges
|
|||
|
Content-Type including Content-Range fields for each part. If a
|
|||
|
Content-Length header field is present in the response, its value
|
|||
|
MUST match the actual number of octets transmitted in the message-
|
|||
|
body.
|
|||
|
|
|||
|
o Date
|
|||
|
|
|||
|
o Cache-Control, ETag, Expires, Content-Location, Last-Modified,
|
|||
|
and/or Vary, if the header field would have been sent in a 200
|
|||
|
response to the same request
|
|||
|
|
|||
|
If the 206 response is the result of an If-Range request, the
|
|||
|
response SHOULD NOT include other representation header fields.
|
|||
|
Otherwise, the response MUST include all of the representation header
|
|||
|
fields that would have been returned with a 200 (OK) response to the
|
|||
|
same request.
|
|||
|
|
|||
|
A cache MUST NOT combine a 206 response with other previously cached
|
|||
|
content if the ETag or Last-Modified headers do not match exactly,
|
|||
|
see Section 4.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 7]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
A cache that does not support the Range and Content-Range headers
|
|||
|
MUST NOT cache 206 (Partial Content) responses. Furthermore, if a
|
|||
|
response uses a range unit that is not understood by the cache, then
|
|||
|
it MUST NOT be cached either.
|
|||
|
|
|||
|
3.2. 416 Requested Range Not Satisfiable
|
|||
|
|
|||
|
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
|
|||
|
ranges-specifier values in this field overlap the current extent of
|
|||
|
the selected resource, and the request did not include an If-Range
|
|||
|
request-header field (Section 5.3). (For byte-ranges, this means
|
|||
|
that the first-byte-pos of all of the byte-range-spec values were
|
|||
|
greater than the current length of the selected resource.)
|
|||
|
|
|||
|
When this status code is returned for a byte-range request, the
|
|||
|
response SHOULD include a Content-Range header field specifying the
|
|||
|
current length of the representation (see Section 5.2). This
|
|||
|
response MUST NOT use the multipart/byteranges content-type.
|
|||
|
|
|||
|
4. Combining Ranges
|
|||
|
|
|||
|
A response might transfer only a subrange of a representation, either
|
|||
|
because the request included one or more Range specifications, or
|
|||
|
because a connection closed prematurely. After several such
|
|||
|
transfers, a cache might have received several ranges of the same
|
|||
|
representation.
|
|||
|
|
|||
|
If a cache has a stored non-empty set of subranges for a
|
|||
|
representation, and an incoming response transfers another subrange,
|
|||
|
the cache MAY combine the new subrange with the existing set if both
|
|||
|
the following conditions are met:
|
|||
|
|
|||
|
o Both the incoming response and the cache entry have a cache
|
|||
|
validator.
|
|||
|
|
|||
|
o The two cache validators match using the strong comparison
|
|||
|
function (see Section 4 of [Part4]).
|
|||
|
|
|||
|
If either requirement is not met, the cache MUST use only the most
|
|||
|
recent partial response (based on the Date values transmitted with
|
|||
|
every response, and using the incoming response if these values are
|
|||
|
equal or missing), and MUST discard the other partial information.
|
|||
|
|
|||
|
5. Header Field Definitions
|
|||
|
|
|||
|
This section defines the syntax and semantics of HTTP/1.1 header
|
|||
|
fields related to range requests and partial responses.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 8]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
5.1. Accept-Ranges
|
|||
|
|
|||
|
The "Accept-Ranges" response-header field allows a resource to
|
|||
|
indicate its acceptance of range requests.
|
|||
|
|
|||
|
Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v
|
|||
|
Accept-Ranges-v = acceptable-ranges
|
|||
|
acceptable-ranges = 1#range-unit / "none"
|
|||
|
|
|||
|
Origin servers that accept byte-range requests MAY send
|
|||
|
|
|||
|
Accept-Ranges: bytes
|
|||
|
|
|||
|
but are not required to do so. Clients MAY generate range requests
|
|||
|
without having received this header for the resource involved. Range
|
|||
|
units are defined in Section 2.
|
|||
|
|
|||
|
Servers that do not accept any kind of range request for a resource
|
|||
|
MAY send
|
|||
|
|
|||
|
Accept-Ranges: none
|
|||
|
|
|||
|
to advise the client not to attempt a range request.
|
|||
|
|
|||
|
5.2. Content-Range
|
|||
|
|
|||
|
The "Content-Range" header field is sent with a partial
|
|||
|
representation to specify where in the full representation the
|
|||
|
payload body is intended to be applied.
|
|||
|
|
|||
|
Range units are defined in Section 2.
|
|||
|
|
|||
|
Content-Range = "Content-Range" ":" OWS Content-Range-v
|
|||
|
Content-Range-v = content-range-spec
|
|||
|
|
|||
|
content-range-spec = byte-content-range-spec
|
|||
|
/ other-content-range-spec
|
|||
|
byte-content-range-spec = bytes-unit SP
|
|||
|
byte-range-resp-spec "/"
|
|||
|
( instance-length / "*" )
|
|||
|
|
|||
|
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
|
|||
|
/ "*"
|
|||
|
|
|||
|
instance-length = 1*DIGIT
|
|||
|
|
|||
|
other-content-range-spec = other-range-unit SP
|
|||
|
other-range-resp-spec
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 9]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
other-range-resp-spec = *CHAR
|
|||
|
|
|||
|
The header SHOULD indicate the total length of the full
|
|||
|
representation, unless this length is unknown or difficult to
|
|||
|
determine. The asterisk "*" character means that the instance-length
|
|||
|
is unknown at the time when the response was generated.
|
|||
|
|
|||
|
Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
|
|||
|
range-resp-spec MUST only specify one range, and MUST contain
|
|||
|
absolute byte positions for both the first and last byte of the
|
|||
|
range.
|
|||
|
|
|||
|
A byte-content-range-spec with a byte-range-resp-spec whose last-
|
|||
|
byte-pos value is less than its first-byte-pos value, or whose
|
|||
|
instance-length value is less than or equal to its last-byte-pos
|
|||
|
value, is invalid. The recipient of an invalid byte-content-range-
|
|||
|
spec MUST ignore it and any content transferred along with it.
|
|||
|
|
|||
|
In the case of a byte range request: A server sending a response with
|
|||
|
status code 416 (Requested range not satisfiable) SHOULD include a
|
|||
|
Content-Range field with a byte-range-resp-spec of "*". The
|
|||
|
instance-length specifies the current length of the selected
|
|||
|
resource. A response with status code 206 (Partial Content) MUST NOT
|
|||
|
include a Content-Range field with a byte-range-resp-spec of "*".
|
|||
|
|
|||
|
Examples of byte-content-range-spec values, assuming that the
|
|||
|
representation contains a total of 1234 bytes:
|
|||
|
|
|||
|
o The first 500 bytes:
|
|||
|
|
|||
|
bytes 0-499/1234
|
|||
|
|
|||
|
o The second 500 bytes:
|
|||
|
|
|||
|
bytes 500-999/1234
|
|||
|
|
|||
|
o All except for the first 500 bytes:
|
|||
|
|
|||
|
bytes 500-1233/1234
|
|||
|
|
|||
|
o The last 500 bytes:
|
|||
|
|
|||
|
bytes 734-1233/1234
|
|||
|
|
|||
|
When an HTTP message includes the content of a single range (for
|
|||
|
example, a response to a request for a single range, or to a request
|
|||
|
for a set of ranges that overlap without any holes), this content is
|
|||
|
transmitted with a Content-Range header, and a Content-Length header
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 10]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
showing the number of bytes actually transferred. For example,
|
|||
|
|
|||
|
HTTP/1.1 206 Partial Content
|
|||
|
Date: Wed, 15 Nov 1995 06:25:24 GMT
|
|||
|
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
|
|||
|
Content-Range: bytes 21010-47021/47022
|
|||
|
Content-Length: 26012
|
|||
|
Content-Type: image/gif
|
|||
|
|
|||
|
When an HTTP message includes the content of multiple ranges (for
|
|||
|
example, a response to a request for multiple non-overlapping
|
|||
|
ranges), these are transmitted as a multipart message. The multipart
|
|||
|
media type used for this purpose is "multipart/byteranges" as defined
|
|||
|
in Appendix A.
|
|||
|
|
|||
|
A response to a request for a single range MUST NOT be sent using the
|
|||
|
multipart/byteranges media type. A response to a request for
|
|||
|
multiple ranges, whose result is a single range, MAY be sent as a
|
|||
|
multipart/byteranges media type with one part. A client that cannot
|
|||
|
decode a multipart/byteranges message MUST NOT ask for multiple
|
|||
|
ranges in a single request.
|
|||
|
|
|||
|
When a client requests multiple ranges in one request, the server
|
|||
|
SHOULD return them in the order that they appeared in the request.
|
|||
|
|
|||
|
If the server ignores a byte-range-spec because it is syntactically
|
|||
|
invalid, the server SHOULD treat the request as if the invalid Range
|
|||
|
header field did not exist. (Normally, this means return a 200
|
|||
|
response containing the full representation).
|
|||
|
|
|||
|
If the server receives a request (other than one including an If-
|
|||
|
Range request-header field) with an unsatisfiable Range request-
|
|||
|
header field (that is, all of whose byte-range-spec values have a
|
|||
|
first-byte-pos value greater than the current length of the selected
|
|||
|
resource), it SHOULD return a response code of 416 (Requested range
|
|||
|
not satisfiable) (Section 3.2).
|
|||
|
|
|||
|
Note: Clients cannot depend on servers to send a 416 (Requested
|
|||
|
range not satisfiable) response instead of a 200 (OK) response for
|
|||
|
an unsatisfiable Range request-header, since not all servers
|
|||
|
implement this request-header.
|
|||
|
|
|||
|
5.3. If-Range
|
|||
|
|
|||
|
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
|
|||
|
cache, it could use the Range request-header with a conditional GET
|
|||
|
(using either or both of If-Unmodified-Since and If-Match.) However,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 11]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
if the condition fails because the representation has been modified,
|
|||
|
the client would then have to make a second request to obtain the
|
|||
|
entire current representation.
|
|||
|
|
|||
|
The "If-Range" request-header field allows a client to "short-
|
|||
|
circuit" the second request. Informally, its meaning is "if the
|
|||
|
representation is unchanged, send me the part(s) that I am missing;
|
|||
|
otherwise, send me the entire new representation".
|
|||
|
|
|||
|
If-Range = "If-Range" ":" OWS If-Range-v
|
|||
|
If-Range-v = entity-tag / HTTP-date
|
|||
|
|
|||
|
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. (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
|
|||
|
header SHOULD only be used together with a Range header, and MUST be
|
|||
|
ignored if the request does not include a Range header, or if the
|
|||
|
server does not support the sub-range operation.
|
|||
|
|
|||
|
If the entity-tag given in the If-Range header matches the current
|
|||
|
cache validator for the representation, then the server SHOULD
|
|||
|
provide the specified sub-range of the representation using a 206
|
|||
|
(Partial Content) response. If the cache validator does not match,
|
|||
|
then the server SHOULD return the entire representation using a 200
|
|||
|
(OK) response.
|
|||
|
|
|||
|
5.4. Range
|
|||
|
|
|||
|
5.4.1. Byte Ranges
|
|||
|
|
|||
|
Since all HTTP representations are transferred as sequences of bytes,
|
|||
|
the concept of a byte range is meaningful for any HTTP
|
|||
|
representation. (However, not all clients and servers need to
|
|||
|
support byte-range operations.)
|
|||
|
|
|||
|
Byte range specifications in HTTP apply to the sequence of bytes in
|
|||
|
the representation body (not necessarily the same as the message-
|
|||
|
body).
|
|||
|
|
|||
|
A byte range operation MAY specify a single range of bytes, or a set
|
|||
|
of ranges within a single representation.
|
|||
|
|
|||
|
byte-ranges-specifier = bytes-unit "=" byte-range-set
|
|||
|
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
|
|||
|
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
|
|||
|
first-byte-pos = 1*DIGIT
|
|||
|
last-byte-pos = 1*DIGIT
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 12]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
The first-byte-pos value in a byte-range-spec gives the byte-offset
|
|||
|
of the first byte in a range. The last-byte-pos value gives the
|
|||
|
byte-offset of the last byte in the range; that is, the byte
|
|||
|
positions specified are inclusive. Byte offsets start at zero.
|
|||
|
|
|||
|
If the last-byte-pos value is present, it MUST be greater than or
|
|||
|
equal to the first-byte-pos in that byte-range-spec, or the byte-
|
|||
|
range-spec is syntactically invalid. The recipient of a byte-range-
|
|||
|
set that includes one or more syntactically invalid byte-range-spec
|
|||
|
values MUST ignore the header field that includes that byte-range-
|
|||
|
set.
|
|||
|
|
|||
|
If the last-byte-pos value is absent, or if the value is greater than
|
|||
|
or equal to the current length of the representation body, last-byte-
|
|||
|
pos is taken to be equal to one less than the current length of the
|
|||
|
representation in bytes.
|
|||
|
|
|||
|
By its choice of last-byte-pos, a client can limit the number of
|
|||
|
bytes retrieved without knowing the size of the representation.
|
|||
|
|
|||
|
suffix-byte-range-spec = "-" suffix-length
|
|||
|
suffix-length = 1*DIGIT
|
|||
|
|
|||
|
A suffix-byte-range-spec is used to specify the suffix of the
|
|||
|
representation body, of a length given by the suffix-length value.
|
|||
|
(That is, this form specifies the last N bytes of a representation.)
|
|||
|
If the representation is shorter than the specified suffix-length,
|
|||
|
the entire representation is used.
|
|||
|
|
|||
|
If a syntactically valid byte-range-set includes at least one byte-
|
|||
|
range-spec whose first-byte-pos is less than the current length of
|
|||
|
the representation, or at least one suffix-byte-range-spec with a
|
|||
|
non-zero suffix-length, then the byte-range-set is satisfiable.
|
|||
|
Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
|
|||
|
set is unsatisfiable, the server SHOULD return a response with a 416
|
|||
|
(Requested range not satisfiable) status code. Otherwise, the server
|
|||
|
SHOULD return a response with a 206 (Partial Content) status code
|
|||
|
containing the satisfiable ranges of the representation.
|
|||
|
|
|||
|
Examples of byte-ranges-specifier values (assuming a representation
|
|||
|
of length 10000):
|
|||
|
|
|||
|
o The first 500 bytes (byte offsets 0-499, inclusive):
|
|||
|
|
|||
|
bytes=0-499
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 13]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
o The second 500 bytes (byte offsets 500-999, inclusive):
|
|||
|
|
|||
|
bytes=500-999
|
|||
|
|
|||
|
o The final 500 bytes (byte offsets 9500-9999, inclusive):
|
|||
|
|
|||
|
bytes=-500
|
|||
|
|
|||
|
Or:
|
|||
|
|
|||
|
bytes=9500-
|
|||
|
|
|||
|
o The first and last bytes only (bytes 0 and 9999):
|
|||
|
|
|||
|
bytes=0-0,-1
|
|||
|
|
|||
|
o Several legal but not canonical specifications of the second 500
|
|||
|
bytes (byte offsets 500-999, inclusive):
|
|||
|
|
|||
|
bytes=500-600,601-999
|
|||
|
bytes=500-700,601-999
|
|||
|
|
|||
|
5.4.2. Range Retrieval Requests
|
|||
|
|
|||
|
The "Range" request-header field defines the GET method (conditional
|
|||
|
or not) to request one or more sub-ranges of the response
|
|||
|
representation body, instead of the entire representation body.
|
|||
|
|
|||
|
Range = "Range" ":" OWS Range-v
|
|||
|
Range-v = byte-ranges-specifier
|
|||
|
/ other-ranges-specifier
|
|||
|
other-ranges-specifier = other-range-unit "=" other-range-set
|
|||
|
other-range-set = 1*CHAR
|
|||
|
|
|||
|
A server MAY ignore the Range header. However, HTTP/1.1 origin
|
|||
|
servers and intermediate caches ought to support byte ranges when
|
|||
|
possible, since Range supports efficient recovery from partially
|
|||
|
failed transfers, and supports efficient partial retrieval of large
|
|||
|
representations.
|
|||
|
|
|||
|
If the server supports the Range header and the specified range or
|
|||
|
ranges are appropriate for the representation:
|
|||
|
|
|||
|
o The presence of a Range header in an unconditional GET modifies
|
|||
|
what is returned if the GET is otherwise successful. In other
|
|||
|
words, the response carries a status code of 206 (Partial Content)
|
|||
|
instead of 200 (OK).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 14]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
o The presence of a Range header in a conditional GET (a request
|
|||
|
using one or both of If-Modified-Since and If-None-Match, or one
|
|||
|
or both of If-Unmodified-Since and If-Match) modifies what is
|
|||
|
returned if the GET is otherwise successful and the condition is
|
|||
|
true. It does not affect the 304 (Not Modified) response returned
|
|||
|
if the conditional is false.
|
|||
|
|
|||
|
In some cases, it might be more appropriate to use the If-Range
|
|||
|
header (see Section 5.3) in addition to the Range header.
|
|||
|
|
|||
|
If a proxy that supports ranges receives a Range request, forwards
|
|||
|
the request to an inbound server, and receives an entire
|
|||
|
representation in reply, it SHOULD only return the requested range to
|
|||
|
its client. It SHOULD store the entire received response in its
|
|||
|
cache if that is consistent with its cache allocation policies.
|
|||
|
|
|||
|
6. IANA Considerations
|
|||
|
|
|||
|
6.1. Status Code Registration
|
|||
|
|
|||
|
The HTTP Status Code Registry located at
|
|||
|
<http://www.iana.org/assignments/http-status-codes> shall be updated
|
|||
|
with the registrations below:
|
|||
|
|
|||
|
+-------+---------------------------------+-------------+
|
|||
|
| Value | Description | Reference |
|
|||
|
+-------+---------------------------------+-------------+
|
|||
|
| 206 | Partial Content | Section 3.1 |
|
|||
|
| 416 | Requested Range Not Satisfiable | Section 3.2 |
|
|||
|
+-------+---------------------------------+-------------+
|
|||
|
|
|||
|
6.2. Header Field Registration
|
|||
|
|
|||
|
The Message Header Field Registry located at <http://www.iana.org/
|
|||
|
assignments/message-headers/message-header-index.html> shall be
|
|||
|
updated with the permanent registrations below (see [RFC3864]):
|
|||
|
|
|||
|
+-------------------+----------+----------+-------------+
|
|||
|
| Header Field Name | Protocol | Status | Reference |
|
|||
|
+-------------------+----------+----------+-------------+
|
|||
|
| Accept-Ranges | http | standard | Section 5.1 |
|
|||
|
| Content-Range | http | standard | Section 5.2 |
|
|||
|
| If-Range | http | standard | Section 5.3 |
|
|||
|
| Range | http | standard | Section 5.4 |
|
|||
|
+-------------------+----------+----------+-------------+
|
|||
|
|
|||
|
The change controller is: "IETF (iesg@ietf.org) - Internet
|
|||
|
Engineering Task Force".
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 15]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
6.3. Range Specifier Registration
|
|||
|
|
|||
|
The registration procedure for HTTP Range Specifiers is defined by
|
|||
|
Section 2.1 of this document.
|
|||
|
|
|||
|
The HTTP Range Specifier Registry shall be created at
|
|||
|
<http://www.iana.org/assignments/http-range-specifiers> and be
|
|||
|
populated with the registrations below:
|
|||
|
|
|||
|
+----------------------+-------------------+----------------------+
|
|||
|
| Range Specifier Name | Description | Reference |
|
|||
|
+----------------------+-------------------+----------------------+
|
|||
|
| bytes | a range of octets | (this specification) |
|
|||
|
+----------------------+-------------------+----------------------+
|
|||
|
|
|||
|
The change controller is: "IETF (iesg@ietf.org) - Internet
|
|||
|
Engineering Task Force".
|
|||
|
|
|||
|
7. Security Considerations
|
|||
|
|
|||
|
No additional security considerations have been identified beyond
|
|||
|
those applicable to HTTP in general [Part1].
|
|||
|
|
|||
|
8. Acknowledgments
|
|||
|
|
|||
|
Most of the specification of ranges is based on work originally done
|
|||
|
by Ari Luotonen and John Franks, with additional input from Steve
|
|||
|
Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
|
|||
|
Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
|
|||
|
Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
|
|||
|
Rizzo, and Bill Weihl.
|
|||
|
|
|||
|
9. References
|
|||
|
|
|||
|
9.1. Normative References
|
|||
|
|
|||
|
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
|
|||
|
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
|
|||
|
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
|
|||
|
and Message Parsing", draft-ietf-httpbis-p1-messaging-11
|
|||
|
(work in progress), August 2010.
|
|||
|
|
|||
|
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
|
|||
|
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
|
|||
|
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
|
|||
|
Requests", draft-ietf-httpbis-p4-conditional-11 (work in
|
|||
|
progress), August 2010.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 16]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|||
|
Extensions (MIME) Part Two: Media Types", RFC 2046,
|
|||
|
November 1996.
|
|||
|
|
|||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
|||
|
Specifications: ABNF", STD 68, RFC 5234, January 2008.
|
|||
|
|
|||
|
9.2. Informative References
|
|||
|
|
|||
|
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
|
|||
|
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
|
|||
|
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
|
|||
|
|
|||
|
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
|
|||
|
Procedures for Message Header Fields", BCP 90, RFC 3864,
|
|||
|
September 2004.
|
|||
|
|
|||
|
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
|
|||
|
Registration Procedures", BCP 13, RFC 4288, December 2005.
|
|||
|
|
|||
|
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
|||
|
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
|
|||
|
May 2008.
|
|||
|
|
|||
|
Appendix A. Internet Media Type multipart/byteranges
|
|||
|
|
|||
|
When an HTTP 206 (Partial Content) response message includes the
|
|||
|
content of multiple ranges (a response to a request for multiple non-
|
|||
|
overlapping ranges), these are transmitted as a multipart message-
|
|||
|
body ([RFC2046], Section 5.1). The media type for this purpose is
|
|||
|
called "multipart/byteranges". The following is to be registered
|
|||
|
with IANA [RFC4288].
|
|||
|
|
|||
|
Note: Despite the name "multipart/byteranges" is not limited to
|
|||
|
the byte ranges only.
|
|||
|
|
|||
|
The multipart/byteranges media type includes one or more parts, each
|
|||
|
with its own Content-Type and Content-Range fields. The required
|
|||
|
boundary parameter specifies the boundary string used to separate
|
|||
|
each body-part.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 17]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
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/Change controller: IESG
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 18]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
For example:
|
|||
|
|
|||
|
HTTP/1.1 206 Partial Content
|
|||
|
Date: Wed, 15 Nov 1995 06:25:24 GMT
|
|||
|
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
|
|||
|
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
|
|||
|
|
|||
|
--THIS_STRING_SEPARATES
|
|||
|
Content-type: application/pdf
|
|||
|
Content-range: bytes 500-999/8000
|
|||
|
|
|||
|
...the first range...
|
|||
|
--THIS_STRING_SEPARATES
|
|||
|
Content-type: application/pdf
|
|||
|
Content-range: bytes 7000-7999/8000
|
|||
|
|
|||
|
...the second range
|
|||
|
--THIS_STRING_SEPARATES--
|
|||
|
|
|||
|
Other example:
|
|||
|
|
|||
|
HTTP/1.1 206 Partial Content
|
|||
|
Date: Tue, 14 Nov 1995 06:25:24 GMT
|
|||
|
Last-Modified: Tue, 14 July 04:58:08 GMT
|
|||
|
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
|
|||
|
|
|||
|
--THIS_STRING_SEPARATES
|
|||
|
Content-type: video/example
|
|||
|
Content-range: exampleunit 1.2-4.3/25
|
|||
|
|
|||
|
...the first range...
|
|||
|
--THIS_STRING_SEPARATES
|
|||
|
Content-type: video/example
|
|||
|
Content-range: exampleunit 11.2-14.3/25
|
|||
|
|
|||
|
...the second range
|
|||
|
--THIS_STRING_SEPARATES--
|
|||
|
|
|||
|
Notes:
|
|||
|
|
|||
|
1. Additional CRLFs MAY precede the first boundary string in the
|
|||
|
body.
|
|||
|
|
|||
|
2. Although [RFC2046] permits the boundary string to be quoted, some
|
|||
|
existing implementations handle a quoted boundary string
|
|||
|
incorrectly.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 19]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
3. A number of browsers and servers were coded to an early draft of
|
|||
|
the byteranges specification to use a media type of multipart/
|
|||
|
x-byteranges, which is almost, but not quite compatible with the
|
|||
|
version documented in HTTP/1.1.
|
|||
|
|
|||
|
Appendix B. Compatibility with Previous Versions
|
|||
|
|
|||
|
B.1. Changes from RFC 2616
|
|||
|
|
|||
|
Clarify that it is not ok to use a weak cache validator in a 206
|
|||
|
response. (Section 3.1)
|
|||
|
|
|||
|
Clarify that multipart/byteranges can consist of a single part.
|
|||
|
(Appendix A)
|
|||
|
|
|||
|
Appendix C. Collected ABNF
|
|||
|
|
|||
|
Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v
|
|||
|
Accept-Ranges-v = acceptable-ranges
|
|||
|
|
|||
|
Content-Range = "Content-Range:" OWS Content-Range-v
|
|||
|
Content-Range-v = content-range-spec
|
|||
|
|
|||
|
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
|
|||
|
|
|||
|
If-Range = "If-Range:" OWS If-Range-v
|
|||
|
If-Range-v = entity-tag / HTTP-date
|
|||
|
|
|||
|
OWS = <OWS, defined in [Part1], Section 1.2.2>
|
|||
|
|
|||
|
Range = "Range:" OWS Range-v
|
|||
|
Range-v = byte-ranges-specifier / other-ranges-specifier
|
|||
|
|
|||
|
acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
|
|||
|
range-unit ] ) ) / "none"
|
|||
|
|
|||
|
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
|
|||
|
instance-length / "*" )
|
|||
|
byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
|
|||
|
byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
|
|||
|
suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
|
|||
|
suffix-byte-range-spec ] ) )
|
|||
|
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
|
|||
|
byte-ranges-specifier = bytes-unit "=" byte-range-set
|
|||
|
bytes-unit = "bytes"
|
|||
|
|
|||
|
content-range-spec = byte-content-range-spec /
|
|||
|
other-content-range-spec
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 20]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
entity-tag = <entity-tag, defined in [Part4], Section 2>
|
|||
|
|
|||
|
first-byte-pos = 1*DIGIT
|
|||
|
|
|||
|
instance-length = 1*DIGIT
|
|||
|
|
|||
|
last-byte-pos = 1*DIGIT
|
|||
|
|
|||
|
other-content-range-spec = other-range-unit SP other-range-resp-spec
|
|||
|
other-range-resp-spec = *CHAR
|
|||
|
other-range-set = 1*CHAR
|
|||
|
other-range-unit = token
|
|||
|
other-ranges-specifier = other-range-unit "=" other-range-set
|
|||
|
|
|||
|
range-unit = bytes-unit / other-range-unit
|
|||
|
|
|||
|
suffix-byte-range-spec = "-" suffix-length
|
|||
|
suffix-length = 1*DIGIT
|
|||
|
|
|||
|
token = <token, defined in [Part1], Section 1.2.2>
|
|||
|
|
|||
|
ABNF diagnostics:
|
|||
|
|
|||
|
; Accept-Ranges defined but not used
|
|||
|
; Content-Range defined but not used
|
|||
|
; If-Range defined but not used
|
|||
|
; Range defined but not used
|
|||
|
|
|||
|
Appendix D. Change Log (to be removed by RFC Editor before publication)
|
|||
|
|
|||
|
D.1. Since RFC2616
|
|||
|
|
|||
|
Extracted relevant partitions from [RFC2616].
|
|||
|
|
|||
|
D.2. Since draft-ietf-httpbis-p5-range-00
|
|||
|
|
|||
|
Closed issues:
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
|
|||
|
validators in 206 responses"
|
|||
|
(<http://purl.org/NET/http-errata#ifrange206>)
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
|
|||
|
Informative references"
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
|
|||
|
to-date references"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 21]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
D.3. Since draft-ietf-httpbis-p5-range-01
|
|||
|
|
|||
|
Closed issues:
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
|
|||
|
RFC4288"
|
|||
|
|
|||
|
Ongoing work on ABNF conversion
|
|||
|
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
|||
|
|
|||
|
o Add explicit references to BNF syntax and rules imported from
|
|||
|
other parts of the specification.
|
|||
|
|
|||
|
D.4. Since draft-ietf-httpbis-p5-range-02
|
|||
|
|
|||
|
Ongoing work on IANA Message Header Registration
|
|||
|
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
|
|||
|
|
|||
|
o Reference RFC 3984, and update header registrations for headers
|
|||
|
defined in this document.
|
|||
|
|
|||
|
D.5. Since draft-ietf-httpbis-p5-range-03
|
|||
|
|
|||
|
D.6. Since draft-ietf-httpbis-p5-range-04
|
|||
|
|
|||
|
Closed issues:
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
|
|||
|
byteranges minimum number of parts"
|
|||
|
|
|||
|
Ongoing work on ABNF conversion
|
|||
|
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
|||
|
|
|||
|
o Use "/" instead of "|" for alternatives.
|
|||
|
|
|||
|
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
|
|||
|
whitespace ("OWS") and required whitespace ("RWS").
|
|||
|
|
|||
|
o Rewrite ABNFs to spell out whitespace rules, factor out header
|
|||
|
value format definitions.
|
|||
|
|
|||
|
D.7. Since draft-ietf-httpbis-p5-range-05
|
|||
|
|
|||
|
Closed issues:
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base
|
|||
|
for *-byte-pos and suffix-length"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 22]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
Ongoing work on Custom Ranges
|
|||
|
(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
|
|||
|
|
|||
|
o Remove bias in favor of byte ranges; allow custom ranges in ABNF.
|
|||
|
|
|||
|
Final work on ABNF conversion
|
|||
|
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
|
|||
|
|
|||
|
o Add appendix containing collected and expanded ABNF, reorganize
|
|||
|
ABNF introduction.
|
|||
|
|
|||
|
D.8. Since draft-ietf-httpbis-p5-range-06
|
|||
|
|
|||
|
Closed issues:
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
|
|||
|
numeric protocol elements"
|
|||
|
|
|||
|
D.9. Since draft-ietf-httpbis-p5-range-07
|
|||
|
|
|||
|
Closed issues:
|
|||
|
|
|||
|
o Fixed discrepancy in the If-Range definition about allowed
|
|||
|
validators.
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/150>: "multipart/
|
|||
|
byteranges for custom range units"
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/151>: "range unit
|
|||
|
missing from other-ranges-specifier in Range header"
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
|
|||
|
registrations for optional status codes"
|
|||
|
|
|||
|
D.10. Since draft-ietf-httpbis-p5-range-08
|
|||
|
|
|||
|
No significant changes.
|
|||
|
|
|||
|
D.11. Since draft-ietf-httpbis-p5-range-09
|
|||
|
|
|||
|
No significant changes.
|
|||
|
|
|||
|
D.12. Since draft-ietf-httpbis-p5-range-10
|
|||
|
|
|||
|
Closed issues:
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
|
|||
|
'Requested Variant'"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 23]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
|
|||
|
entity / representation / variant terminology"
|
|||
|
|
|||
|
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
|
|||
|
removing the 'changes from 2068' sections"
|
|||
|
|
|||
|
Ongoing work on Custom Ranges
|
|||
|
(<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
|
|||
|
|
|||
|
o Add IANA registry.
|
|||
|
|
|||
|
Index
|
|||
|
|
|||
|
2
|
|||
|
206 Partial Content (status code) 7
|
|||
|
|
|||
|
4
|
|||
|
416 Requested Range Not Satisfiable (status code) 8
|
|||
|
|
|||
|
A
|
|||
|
Accept-Ranges header 9
|
|||
|
|
|||
|
C
|
|||
|
Content-Range header 9
|
|||
|
|
|||
|
G
|
|||
|
Grammar
|
|||
|
Accept-Ranges 9
|
|||
|
Accept-Ranges-v 9
|
|||
|
acceptable-ranges 9
|
|||
|
byte-content-range-spec 9
|
|||
|
byte-range-resp-spec 9
|
|||
|
byte-range-set 12
|
|||
|
byte-range-spec 12
|
|||
|
byte-ranges-specifier 12
|
|||
|
bytes-unit 6
|
|||
|
Content-Range 9
|
|||
|
content-range-spec 9
|
|||
|
Content-Range-v 9
|
|||
|
first-byte-pos 12
|
|||
|
If-Range 12
|
|||
|
If-Range-v 12
|
|||
|
instance-length 9
|
|||
|
last-byte-pos 12
|
|||
|
other-range-unit 6
|
|||
|
Range 14
|
|||
|
range-unit 6
|
|||
|
ranges-specifier 12
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 24]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
suffix-byte-range-spec 13
|
|||
|
suffix-length 13
|
|||
|
|
|||
|
H
|
|||
|
Headers
|
|||
|
Accept-Ranges 9
|
|||
|
Content-Range 9
|
|||
|
If-Range 11
|
|||
|
Range 12
|
|||
|
|
|||
|
I
|
|||
|
If-Range header 11
|
|||
|
|
|||
|
M
|
|||
|
Media Type
|
|||
|
multipart/byteranges 17
|
|||
|
multipart/x-byteranges 20
|
|||
|
multipart/byteranges Media Type 17
|
|||
|
multipart/x-byteranges Media Type 20
|
|||
|
|
|||
|
R
|
|||
|
Range header 12
|
|||
|
|
|||
|
S
|
|||
|
Status Codes
|
|||
|
206 Partial Content 7
|
|||
|
416 Requested Range Not Satisfiable 8
|
|||
|
|
|||
|
Authors' Addresses
|
|||
|
|
|||
|
Roy T. Fielding (editor)
|
|||
|
Day Software
|
|||
|
23 Corporate Plaza DR, Suite 280
|
|||
|
Newport Beach, CA 92660
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1-949-706-5300
|
|||
|
Fax: +1-949-706-5305
|
|||
|
EMail: fielding@gbiv.com
|
|||
|
URI: http://roy.gbiv.com/
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 25]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
Jim Gettys
|
|||
|
Alcatel-Lucent Bell Labs
|
|||
|
21 Oak Knoll Road
|
|||
|
Carlisle, MA 01741
|
|||
|
USA
|
|||
|
|
|||
|
EMail: jg@freedesktop.org
|
|||
|
URI: http://gettys.wordpress.com/
|
|||
|
|
|||
|
|
|||
|
Jeffrey C. Mogul
|
|||
|
Hewlett-Packard Company
|
|||
|
HP Labs, Large Scale Systems Group
|
|||
|
1501 Page Mill Road, MS 1177
|
|||
|
Palo Alto, CA 94304
|
|||
|
USA
|
|||
|
|
|||
|
EMail: JeffMogul@acm.org
|
|||
|
|
|||
|
|
|||
|
Henrik Frystyk Nielsen
|
|||
|
Microsoft Corporation
|
|||
|
1 Microsoft Way
|
|||
|
Redmond, WA 98052
|
|||
|
USA
|
|||
|
|
|||
|
EMail: henrikn@microsoft.com
|
|||
|
|
|||
|
|
|||
|
Larry Masinter
|
|||
|
Adobe Systems, Incorporated
|
|||
|
345 Park Ave
|
|||
|
San Jose, CA 95110
|
|||
|
USA
|
|||
|
|
|||
|
EMail: LMM@acm.org
|
|||
|
URI: http://larry.masinter.net/
|
|||
|
|
|||
|
|
|||
|
Paul J. Leach
|
|||
|
Microsoft Corporation
|
|||
|
1 Microsoft Way
|
|||
|
Redmond, WA 98052
|
|||
|
|
|||
|
EMail: paulle@microsoft.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 26]
|
|||
|
|
|||
|
Internet-Draft HTTP/1.1, Part 5 August 2010
|
|||
|
|
|||
|
|
|||
|
Tim Berners-Lee
|
|||
|
World Wide Web Consortium
|
|||
|
MIT Computer Science and Artificial Intelligence Laboratory
|
|||
|
The Stata Center, Building 32
|
|||
|
32 Vassar Street
|
|||
|
Cambridge, MA 02139
|
|||
|
USA
|
|||
|
|
|||
|
EMail: timbl@w3.org
|
|||
|
URI: http://www.w3.org/People/Berners-Lee/
|
|||
|
|
|||
|
|
|||
|
Yves Lafon (editor)
|
|||
|
World Wide Web Consortium
|
|||
|
W3C / ERCIM
|
|||
|
2004, rte des Lucioles
|
|||
|
Sophia-Antipolis, AM 06902
|
|||
|
France
|
|||
|
|
|||
|
EMail: ylafon@w3.org
|
|||
|
URI: http://www.raubacapeu.net/people/yves/
|
|||
|
|
|||
|
|
|||
|
Julian F. Reschke (editor)
|
|||
|
greenbytes GmbH
|
|||
|
Hafenweg 16
|
|||
|
Muenster, NW 48155
|
|||
|
Germany
|
|||
|
|
|||
|
Phone: +49 251 2807760
|
|||
|
Fax: +49 251 2807761
|
|||
|
EMail: julian.reschke@greenbytes.de
|
|||
|
URI: http://greenbytes.de/tech/webdav/
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Fielding, et al. Expires February 5, 2011 [Page 27]
|
|||
|
|