idnits 2.17.1
draft-ietf-httpbis-p5-range-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 18, 2011) is 4757 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p1-messaging-14
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p4-conditional-14
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 4288
(Obsoleted by RFC 6838)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 HTTPbis Working Group R. Fielding, Ed.
3 Internet-Draft Adobe
4 Obsoletes: 2616 (if approved) J. Gettys
5 Intended status: Standards Track Alcatel-Lucent
6 Expires: October 20, 2011 J. Mogul
7 HP
8 H. Frystyk
9 Microsoft
10 L. Masinter
11 Adobe
12 P. Leach
13 Microsoft
14 T. Berners-Lee
15 W3C/MIT
16 Y. Lafon, Ed.
17 W3C
18 J. Reschke, Ed.
19 greenbytes
20 April 18, 2011
22 HTTP/1.1, part 5: Range Requests and Partial Responses
23 draft-ietf-httpbis-p5-range-14
25 Abstract
27 The Hypertext Transfer Protocol (HTTP) is an application-level
28 protocol for distributed, collaborative, hypermedia information
29 systems. HTTP has been in use by the World Wide Web global
30 information initiative since 1990. This document is Part 5 of the
31 seven-part specification that defines the protocol referred to as
32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines
33 range-specific requests and the rules for constructing and combining
34 responses to those requests.
36 Editorial Note (To be removed by RFC Editor)
38 Discussion of this draft should take place on the HTTPBIS working
39 group mailing list (ietf-http-wg@w3.org), which is archived at
40 .
42 The current issues list is at
43 and related
44 documents (including fancy diffs) can be found at
45 .
47 The changes in this draft are summarized in Appendix D.15.
49 Status of This Memo
51 This Internet-Draft is submitted in full conformance with the
52 provisions of BCP 78 and BCP 79.
54 Internet-Drafts are working documents of the Internet Engineering
55 Task Force (IETF). Note that other groups may also distribute
56 working documents as Internet-Drafts. The list of current Internet-
57 Drafts is at http://datatracker.ietf.org/drafts/current/.
59 Internet-Drafts are draft documents valid for a maximum of six months
60 and may be updated, replaced, or obsoleted by other documents at any
61 time. It is inappropriate to use Internet-Drafts as reference
62 material or to cite them other than as "work in progress."
64 This Internet-Draft will expire on October 20, 2011.
66 Copyright Notice
68 Copyright (c) 2011 IETF Trust and the persons identified as the
69 document authors. All rights reserved.
71 This document is subject to BCP 78 and the IETF Trust's Legal
72 Provisions Relating to IETF Documents
73 (http://trustee.ietf.org/license-info) in effect on the date of
74 publication of this document. Please review these documents
75 carefully, as they describe your rights and restrictions with respect
76 to this document. Code Components extracted from this document must
77 include Simplified BSD License text as described in Section 4.e of
78 the Trust Legal Provisions and are provided without warranty as
79 described in the Simplified BSD License.
81 This document may contain material from IETF Documents or IETF
82 Contributions published or made publicly available before November
83 10, 2008. The person(s) controlling the copyright in some of this
84 material may not have granted the IETF Trust the right to allow
85 modifications of such material outside the IETF Standards Process.
86 Without obtaining an adequate license from the person(s) controlling
87 the copyright in such materials, this document may not be modified
88 outside the IETF Standards Process, and derivative works of it may
89 not be created outside the IETF Standards Process, except to format
90 it for publication as an RFC or to translate it into languages other
91 than English.
93 Table of Contents
95 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
96 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
97 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
98 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
99 1.2.2. ABNF Rules defined in other Parts of the
100 Specification . . . . . . . . . . . . . . . . . . . . 5
101 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5
102 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5
103 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6
104 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6
105 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7
106 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7
107 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
108 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8
109 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8
110 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
111 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11
112 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
113 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13
114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
115 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
116 6.2. Header Field Registration . . . . . . . . . . . . . . . . 14
117 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15
118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
119 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
121 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
122 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
123 Appendix A. Internet Media Type multipart/byteranges . . . . . . 16
124 Appendix B. Compatibility with Previous Versions . . . . . . . . 19
125 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
126 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 19
127 Appendix D. Change Log (to be removed by RFC Editor before
128 publication) . . . . . . . . . . . . . . . . . . . . 21
129 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 21
130 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
131 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 21
132 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 21
133 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22
134 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22
135 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
136 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 22
137 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23
138 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23
139 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23
140 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23
141 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 23
142 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 24
143 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 24
144 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
146 1. Introduction
148 HTTP clients often encounter interrupted data transfers as a result
149 of cancelled requests or dropped connections. When a cache has
150 stored a partial representation, it is desirable to request the
151 remainder of that representation in a subsequent request rather than
152 transfer the entire representation. There are also a number of Web
153 applications that benefit from being able to request only a subset of
154 a larger representation, such as a single page of a very large
155 document or only part of an image to be rendered by a device with
156 limited local storage.
158 This document defines HTTP/1.1 range requests, partial responses, and
159 the multipart/byteranges media type. The protocol for range requests
160 is an OPTIONAL feature of HTTP, designed so resources or recipients
161 that do not implement this feature can respond as if it is a normal
162 GET request without impacting interoperability. Partial responses
163 are indicated by a distinct status code to not be mistaken for full
164 responses by intermediate caches that might not implement the
165 feature.
167 Although the HTTP range request mechanism is designed to allow for
168 extensible range types, this specification only defines requests for
169 byte ranges.
171 1.1. Requirements
173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
175 document are to be interpreted as described in [RFC2119].
177 An implementation is not compliant if it fails to satisfy one or more
178 of the "MUST" or "REQUIRED" level requirements for the protocols it
179 implements. An implementation that satisfies all the "MUST" or
180 "REQUIRED" level and all the "SHOULD" level requirements for its
181 protocols is said to be "unconditionally compliant"; one that
182 satisfies all the "MUST" level requirements but not all the "SHOULD"
183 level requirements for its protocols is said to be "conditionally
184 compliant".
186 1.2. Syntax Notation
188 This specification uses the ABNF syntax defined in Section 1.2 of
189 [Part1] (which extends the syntax defined in [RFC5234] with a list
190 rule). Appendix C shows the collected ABNF, with the list rule
191 expanded.
193 The following core rules are included by reference, as defined in
195 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
196 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
197 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
198 sequence of data), SP (space), VCHAR (any visible USASCII character),
199 and WSP (whitespace).
201 1.2.1. Core Rules
203 The core rules below are defined in Section 1.2.2 of [Part1]:
205 token =
206 OWS =
208 1.2.2. ABNF Rules defined in other Parts of the Specification
210 The ABNF rules below are defined in other parts:
212 HTTP-date =
214 entity-tag =
216 2. Range Units
218 HTTP/1.1 allows a client to request that only part (a range) of the
219 representation be included within the response. HTTP/1.1 uses range
220 units in the Range (Section 5.4) and Content-Range (Section 5.2)
221 header fields. A representation can be broken down into subranges
222 according to various structural units.
224 range-unit = bytes-unit / other-range-unit
225 bytes-unit = "bytes"
226 other-range-unit = token
228 HTTP/1.1 has been designed to allow implementations of applications
229 that do not depend on knowledge of ranges. The only range unit
230 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
231 as described in Section 2.1.
233 If a range unit is not understood in a request, a server MUST ignore
234 the whole Range header field (Section 5.4). If a range unit is not
235 understood in a response, an intermediary SHOULD pass the response to
236 the client; a client MUST fail.
238 2.1. Range Specifier Registry
240 The HTTP Range Specifier Registry defines the name space for the
241 range specifier names.
243 Registrations MUST include the following fields:
245 o Name
247 o Description
249 o Pointer to specification text
251 Values to be added to this name space are subject to IETF review
252 ([RFC5226], Section 4.1).
254 The registry itself is maintained at
255 .
257 3. Status Code Definitions
259 3.1. 206 Partial Content
261 The server has fulfilled the partial GET request for the resource.
262 The request MUST have included a Range header field (Section 5.4)
263 indicating the desired range, and MAY have included an If-Range
264 header field (Section 5.3) to make the request conditional.
266 The response MUST include the following header fields:
268 o Either a Content-Range header field (Section 5.2) indicating the
269 range included with this response, or a multipart/byteranges
270 Content-Type including Content-Range fields for each part. If a
271 Content-Length header field is present in the response, its value
272 MUST match the actual number of octets transmitted in the message-
273 body.
275 o Date
277 o Cache-Control, ETag, Expires, Content-Location, Last-Modified,
278 and/or Vary, if the header field would have been sent in a 200
279 response to the same request
281 If the 206 response is the result of an If-Range request, the
282 response SHOULD NOT include other representation header fields.
283 Otherwise, the response MUST include all of the representation header
284 fields that would have been returned with a 200 (OK) response to the
285 same request.
287 A cache MUST NOT combine a 206 response with other previously cached
288 content if the ETag or Last-Modified header fields do not match
289 exactly, see Section 4.
291 A cache that does not support the Range and Content-Range header
292 fields MUST NOT cache 206 (Partial Content) responses. Furthermore,
293 if a response uses a range unit that is not understood by the cache,
294 then it MUST NOT be cached either.
296 3.2. 416 Requested Range Not Satisfiable
298 A server SHOULD return a response with this status code if a request
299 included a Range header field (Section 5.4), and none of the ranges-
300 specifier values in this field overlap the current extent of the
301 selected resource, and the request did not include an If-Range header
302 field (Section 5.3). (For byte-ranges, this means that the first-
303 byte-pos of all of the byte-range-spec values were greater than the
304 current length of the selected resource.)
306 When this status code is returned for a byte-range request, the
307 response SHOULD include a Content-Range header field specifying the
308 current length of the representation (see Section 5.2). This
309 response MUST NOT use the multipart/byteranges content-type.
311 4. Combining Ranges
313 A response might transfer only a subrange of a representation, either
314 because the request included one or more Range specifications, or
315 because a connection closed prematurely. After several such
316 transfers, a cache might have received several ranges of the same
317 representation.
319 If a cache has a stored non-empty set of subranges for a
320 representation, and an incoming response transfers another subrange,
321 the cache MAY combine the new subrange with the existing set if both
322 the following conditions are met:
324 o Both the incoming response and the cache entry have a cache
325 validator.
327 o The two cache validators match using the strong comparison
328 function (see Section 2.2.2 of [Part4]).
330 If either requirement is not met, the cache MUST use only the most
331 recent partial response (based on the Date values transmitted with
332 every response, and using the incoming response if these values are
333 equal or missing), and MUST discard the other partial information.
335 5. Header Field Definitions
337 This section defines the syntax and semantics of HTTP/1.1 header
338 fields related to range requests and partial responses.
340 5.1. Accept-Ranges
342 The "Accept-Ranges" header field allows a resource to indicate its
343 acceptance of range requests.
345 Accept-Ranges = acceptable-ranges
346 acceptable-ranges = 1#range-unit / "none"
348 Origin servers that accept byte-range requests MAY send
350 Accept-Ranges: bytes
352 but are not required to do so. Clients MAY generate range requests
353 without having received this header field for the resource involved.
354 Range units are defined in Section 2.
356 Servers that do not accept any kind of range request for a resource
357 MAY send
359 Accept-Ranges: none
361 to advise the client not to attempt a range request.
363 5.2. Content-Range
365 The "Content-Range" header field is sent with a partial
366 representation to specify where in the full representation the
367 payload body is intended to be applied.
369 Range units are defined in Section 2.
371 Content-Range = content-range-spec
373 content-range-spec = byte-content-range-spec
374 / other-content-range-spec
375 byte-content-range-spec = bytes-unit SP
376 byte-range-resp-spec "/"
377 ( instance-length / "*" )
379 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
380 / "*"
382 instance-length = 1*DIGIT
384 other-content-range-spec = other-range-unit SP
385 other-range-resp-spec
386 other-range-resp-spec = *CHAR
388 The header field SHOULD indicate the total length of the full
389 representation, unless this length is unknown or difficult to
390 determine. The asterisk "*" character means that the instance-length
391 is unknown at the time when the response was generated.
393 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
394 range-resp-spec MUST only specify one range, and MUST contain
395 absolute byte positions for both the first and last byte of the
396 range.
398 A byte-content-range-spec with a byte-range-resp-spec whose last-
399 byte-pos value is less than its first-byte-pos value, or whose
400 instance-length value is less than or equal to its last-byte-pos
401 value, is invalid. The recipient of an invalid byte-content-range-
402 spec MUST ignore it and any content transferred along with it.
404 In the case of a byte range request: A server sending a response with
405 status code 416 (Requested range not satisfiable) SHOULD include a
406 Content-Range field with a byte-range-resp-spec of "*". The
407 instance-length specifies the current length of the selected
408 resource. A response with status code 206 (Partial Content) MUST NOT
409 include a Content-Range field with a byte-range-resp-spec of "*".
411 Examples of byte-content-range-spec values, assuming that the
412 representation contains a total of 1234 bytes:
414 o The first 500 bytes:
416 bytes 0-499/1234
418 o The second 500 bytes:
420 bytes 500-999/1234
422 o All except for the first 500 bytes:
424 bytes 500-1233/1234
426 o The last 500 bytes:
428 bytes 734-1233/1234
430 When an HTTP message includes the content of a single range (for
431 example, a response to a request for a single range, or to a request
432 for a set of ranges that overlap without any holes), this content is
433 transmitted with a Content-Range header field, and a Content-Length
434 header field showing the number of bytes actually transferred. For
435 example,
436 HTTP/1.1 206 Partial Content
437 Date: Wed, 15 Nov 1995 06:25:24 GMT
438 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
439 Content-Range: bytes 21010-47021/47022
440 Content-Length: 26012
441 Content-Type: image/gif
443 When an HTTP message includes the content of multiple ranges (for
444 example, a response to a request for multiple non-overlapping
445 ranges), these are transmitted as a multipart message. The multipart
446 media type used for this purpose is "multipart/byteranges" as defined
447 in Appendix A.
449 A response to a request for a single range MUST NOT be sent using the
450 multipart/byteranges media type. A response to a request for
451 multiple ranges, whose result is a single range, MAY be sent as a
452 multipart/byteranges media type with one part. A client that cannot
453 decode a multipart/byteranges message MUST NOT ask for multiple
454 ranges in a single request.
456 When a client requests multiple ranges in one request, the server
457 SHOULD return them in the order that they appeared in the request.
459 If the server ignores a byte-range-spec because it is syntactically
460 invalid, the server SHOULD treat the request as if the invalid Range
461 header field did not exist. (Normally, this means return a 200
462 response containing the full representation).
464 If the server receives a request (other than one including an If-
465 Range header field) with an unsatisfiable Range header field (that
466 is, all of whose byte-range-spec values have a first-byte-pos value
467 greater than the current length of the selected resource), it SHOULD
468 return a response code of 416 (Requested range not satisfiable)
469 (Section 3.2).
471 Note: Clients cannot depend on servers to send a 416 (Requested
472 range not satisfiable) response instead of a 200 (OK) response for
473 an unsatisfiable Range header field, since not all servers
474 implement this header field.
476 5.3. If-Range
478 If a client has a partial copy of a representation in its cache, and
479 wishes to have an up-to-date copy of the entire representation in its
480 cache, it could use the Range header field with a conditional GET
481 (using either or both of If-Unmodified-Since and If-Match.) However,
482 if the condition fails because the representation has been modified,
483 the client would then have to make a second request to obtain the
484 entire current representation.
486 The "If-Range" header field allows a client to "short-circuit" the
487 second request. Informally, its meaning is "if the representation is
488 unchanged, send me the part(s) that I am missing; otherwise, send me
489 the entire new representation".
491 If-Range = entity-tag / HTTP-date
493 Only a strong validator (Section 2.2.2 of [Part4]) is usable for
494 range retrieval, since otherwise the client might end up with an
495 internally inconsistent representation. Clients MUST NOT use weak
496 validators in range requests. A cache or origin server receiving a
497 conditional range request MUST use the strong comparison function to
498 evaluate the condition.
500 If the client has no entity-tag for a representation, but does have a
501 Last-Modified date, it MAY use that date in an If-Range header field.
502 (The server can distinguish between a valid HTTP-date and any form of
503 entity-tag by examining no more than two characters.) The If-Range
504 header field SHOULD only be used together with a Range header field,
505 and MUST be ignored if the request does not include a Range header
506 field, or if the server does not support the sub-range operation.
508 If a client wishes to perform a sub-range retrieval on a value for
509 which it has only a Last-Modified time and no opaque validator, it
510 MAY do this only if the Last-Modified time is strong in the sense
511 described in Section 2.1.2 of [Part4].
513 If the entity-tag given in the If-Range header field matches the
514 current cache validator for the representation, then the server
515 SHOULD provide the specified sub-range of the representation using a
516 206 (Partial Content) response. If the cache validator does not
517 match, then the server SHOULD return the entire representation using
518 a 200 (OK) response.
520 5.4. Range
522 5.4.1. Byte Ranges
524 Since all HTTP representations are transferred as sequences of bytes,
525 the concept of a byte range is meaningful for any HTTP
526 representation. (However, not all clients and servers need to
527 support byte-range operations.)
529 Byte range specifications in HTTP apply to the sequence of bytes in
530 the representation body (not necessarily the same as the message-
531 body).
533 A byte range operation MAY specify a single range of bytes, or a set
534 of ranges within a single representation.
536 byte-ranges-specifier = bytes-unit "=" byte-range-set
537 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
538 byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
539 first-byte-pos = 1*DIGIT
540 last-byte-pos = 1*DIGIT
542 The first-byte-pos value in a byte-range-spec gives the byte-offset
543 of the first byte in a range. The last-byte-pos value gives the
544 byte-offset of the last byte in the range; that is, the byte
545 positions specified are inclusive. Byte offsets start at zero.
547 If the last-byte-pos value is present, it MUST be greater than or
548 equal to the first-byte-pos in that byte-range-spec, or the byte-
549 range-spec is syntactically invalid. The recipient of a byte-range-
550 set that includes one or more syntactically invalid byte-range-spec
551 values MUST ignore the header field that includes that byte-range-
552 set.
554 If the last-byte-pos value is absent, or if the value is greater than
555 or equal to the current length of the representation body, last-byte-
556 pos is taken to be equal to one less than the current length of the
557 representation in bytes.
559 By its choice of last-byte-pos, a client can limit the number of
560 bytes retrieved without knowing the size of the representation.
562 suffix-byte-range-spec = "-" suffix-length
563 suffix-length = 1*DIGIT
565 A suffix-byte-range-spec is used to specify the suffix of the
566 representation body, of a length given by the suffix-length value.
567 (That is, this form specifies the last N bytes of a representation.)
568 If the representation is shorter than the specified suffix-length,
569 the entire representation is used.
571 If a syntactically valid byte-range-set includes at least one byte-
572 range-spec whose first-byte-pos is less than the current length of
573 the representation, or at least one suffix-byte-range-spec with a
574 non-zero suffix-length, then the byte-range-set is satisfiable.
575 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
576 set is unsatisfiable, the server SHOULD return a response with a 416
577 (Requested range not satisfiable) status code. Otherwise, the server
578 SHOULD return a response with a 206 (Partial Content) status code
579 containing the satisfiable ranges of the representation.
581 Examples of byte-ranges-specifier values (assuming a representation
582 of length 10000):
584 o The first 500 bytes (byte offsets 0-499, inclusive):
586 bytes=0-499
588 o The second 500 bytes (byte offsets 500-999, inclusive):
590 bytes=500-999
592 o The final 500 bytes (byte offsets 9500-9999, inclusive):
594 bytes=-500
596 Or:
598 bytes=9500-
600 o The first and last bytes only (bytes 0 and 9999):
602 bytes=0-0,-1
604 o Several legal but not canonical specifications of the second 500
605 bytes (byte offsets 500-999, inclusive):
607 bytes=500-600,601-999
608 bytes=500-700,601-999
610 5.4.2. Range Retrieval Requests
612 The "Range" header field defines the GET method (conditional or not)
613 to request one or more sub-ranges of the response representation
614 body, instead of the entire representation body.
616 Range = byte-ranges-specifier / other-ranges-specifier
617 other-ranges-specifier = other-range-unit "=" other-range-set
618 other-range-set = 1*CHAR
620 A server MAY ignore the Range header field. However, HTTP/1.1 origin
621 servers and intermediate caches ought to support byte ranges when
622 possible, since Range supports efficient recovery from partially
623 failed transfers, and supports efficient partial retrieval of large
624 representations.
626 If the server supports the Range header field and the specified range
627 or ranges are appropriate for the representation:
629 o The presence of a Range header field in an unconditional GET
630 modifies what is returned if the GET is otherwise successful. In
631 other words, the response carries a status code of 206 (Partial
632 Content) instead of 200 (OK).
634 o The presence of a Range header field in a conditional GET (a
635 request using one or both of If-Modified-Since and If-None-Match,
636 or one or both of If-Unmodified-Since and If-Match) modifies what
637 is returned if the GET is otherwise successful and the condition
638 is true. It does not affect the 304 (Not Modified) response
639 returned if the conditional is false.
641 In some cases, it might be more appropriate to use the If-Range
642 header field (see Section 5.3) in addition to the Range header field.
644 If a proxy that supports ranges receives a Range request, forwards
645 the request to an inbound server, and receives an entire
646 representation in reply, it MAY only return the requested range to
647 its client.
649 6. IANA Considerations
651 6.1. Status Code Registration
653 The HTTP Status Code Registry located at
654 shall be updated
655 with the registrations below:
657 +-------+---------------------------------+-------------+
658 | Value | Description | Reference |
659 +-------+---------------------------------+-------------+
660 | 206 | Partial Content | Section 3.1 |
661 | 416 | Requested Range Not Satisfiable | Section 3.2 |
662 +-------+---------------------------------+-------------+
664 6.2. Header Field Registration
666 The Message Header Field Registry located at shall be
668 updated with the permanent registrations below (see [RFC3864]):
670 +-------------------+----------+----------+-------------+
671 | Header Field Name | Protocol | Status | Reference |
672 +-------------------+----------+----------+-------------+
673 | Accept-Ranges | http | standard | Section 5.1 |
674 | Content-Range | http | standard | Section 5.2 |
675 | If-Range | http | standard | Section 5.3 |
676 | Range | http | standard | Section 5.4 |
677 +-------------------+----------+----------+-------------+
679 The change controller is: "IETF (iesg@ietf.org) - Internet
680 Engineering Task Force".
682 6.3. Range Specifier Registration
684 The registration procedure for HTTP Range Specifiers is defined by
685 Section 2.1 of this document.
687 The HTTP Range Specifier Registry shall be created at
688 and be
689 populated with the registrations below:
691 +----------------------+-------------------+----------------------+
692 | Range Specifier Name | Description | Reference |
693 +----------------------+-------------------+----------------------+
694 | bytes | a range of octets | (this specification) |
695 +----------------------+-------------------+----------------------+
697 The change controller is: "IETF (iesg@ietf.org) - Internet
698 Engineering Task Force".
700 7. Security Considerations
702 No additional security considerations have been identified beyond
703 those applicable to HTTP in general [Part1].
705 8. Acknowledgments
707 Most of the specification of ranges is based on work originally done
708 by Ari Luotonen and John Franks, with additional input from Steve
709 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
710 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
711 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
712 Rizzo, and Bill Weihl.
714 9. References
715 9.1. Normative References
717 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
718 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
719 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
720 and Message Parsing", draft-ietf-httpbis-p1-messaging-14
721 (work in progress), April 2011.
723 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
724 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
725 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
726 Requests", draft-ietf-httpbis-p4-conditional-14 (work in
727 progress), April 2011.
729 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
730 Extensions (MIME) Part Two: Media Types", RFC 2046,
731 November 1996.
733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
734 Requirement Levels", BCP 14, RFC 2119, March 1997.
736 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
737 Specifications: ABNF", STD 68, RFC 5234, January 2008.
739 9.2. Informative References
741 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
742 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
743 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
745 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
746 Procedures for Message Header Fields", BCP 90, RFC 3864,
747 September 2004.
749 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
750 Registration Procedures", BCP 13, RFC 4288, December 2005.
752 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
753 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
754 May 2008.
756 Appendix A. Internet Media Type multipart/byteranges
758 When an HTTP 206 (Partial Content) response message includes the
759 content of multiple ranges (a response to a request for multiple non-
760 overlapping ranges), these are transmitted as a multipart message-
761 body ([RFC2046], Section 5.1). The media type for this purpose is
762 called "multipart/byteranges". The following is to be registered
763 with IANA [RFC4288].
765 Note: Despite the name "multipart/byteranges" is not limited to
766 the byte ranges only.
768 The multipart/byteranges media type includes one or more parts, each
769 with its own Content-Type and Content-Range fields. The required
770 boundary parameter specifies the boundary string used to separate
771 each body-part.
773 Type name: multipart
775 Subtype name: byteranges
777 Required parameters: boundary
779 Optional parameters: none
781 Encoding considerations: only "7bit", "8bit", or "binary" are
782 permitted
784 Security considerations: none
786 Interoperability considerations: none
788 Published specification: This specification (see Appendix A).
790 Applications that use this media type:
792 Additional information:
794 Magic number(s): none
796 File extension(s): none
798 Macintosh file type code(s): none
800 Person and email address to contact for further information: See
801 Authors Section.
803 Intended usage: COMMON
805 Restrictions on usage: none
807 Author/Change controller: IESG
808 For example:
810 HTTP/1.1 206 Partial Content
811 Date: Wed, 15 Nov 1995 06:25:24 GMT
812 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
813 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
815 --THIS_STRING_SEPARATES
816 Content-type: application/pdf
817 Content-range: bytes 500-999/8000
819 ...the first range...
820 --THIS_STRING_SEPARATES
821 Content-type: application/pdf
822 Content-range: bytes 7000-7999/8000
824 ...the second range
825 --THIS_STRING_SEPARATES--
827 Other example:
829 HTTP/1.1 206 Partial Content
830 Date: Tue, 14 Nov 1995 06:25:24 GMT
831 Last-Modified: Tue, 14 July 04:58:08 GMT
832 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
834 --THIS_STRING_SEPARATES
835 Content-type: video/example
836 Content-range: exampleunit 1.2-4.3/25
838 ...the first range...
839 --THIS_STRING_SEPARATES
840 Content-type: video/example
841 Content-range: exampleunit 11.2-14.3/25
843 ...the second range
844 --THIS_STRING_SEPARATES--
846 Notes:
848 1. Additional CRLFs MAY precede the first boundary string in the
849 body.
851 2. Although [RFC2046] permits the boundary string to be quoted, some
852 existing implementations handle a quoted boundary string
853 incorrectly.
855 3. A number of browsers and servers were coded to an early draft of
856 the byteranges specification to use a media type of multipart/
857 x-byteranges, which is almost, but not quite compatible with the
858 version documented in HTTP/1.1.
860 Appendix B. Compatibility with Previous Versions
862 B.1. Changes from RFC 2616
864 Clarify that it is not ok to use a weak cache validator in a 206
865 response. (Section 3.1)
867 Change ABNF productions for header fields to only define the field
868 value. (Section 5)
870 Clarify that multipart/byteranges can consist of a single part.
871 (Appendix A)
873 Appendix C. Collected ABNF
874 Accept-Ranges = acceptable-ranges
876 Content-Range = content-range-spec
878 HTTP-date =
880 If-Range = entity-tag / HTTP-date
882 OWS =
884 Range = byte-ranges-specifier / other-ranges-specifier
886 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
887 range-unit ] ) ) / "none"
889 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
890 instance-length / "*" )
891 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
892 byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
893 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
894 suffix-byte-range-spec ] ) )
895 byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
896 byte-ranges-specifier = bytes-unit "=" byte-range-set
897 bytes-unit = "bytes"
899 content-range-spec = byte-content-range-spec /
900 other-content-range-spec
902 entity-tag =
904 first-byte-pos = 1*DIGIT
906 instance-length = 1*DIGIT
908 last-byte-pos = 1*DIGIT
910 other-content-range-spec = other-range-unit SP other-range-resp-spec
911 other-range-resp-spec = *CHAR
912 other-range-set = 1*CHAR
913 other-range-unit = token
914 other-ranges-specifier = other-range-unit "=" other-range-set
916 range-unit = bytes-unit / other-range-unit
918 suffix-byte-range-spec = "-" suffix-length
919 suffix-length = 1*DIGIT
921 token =
922 ABNF diagnostics:
924 ; Accept-Ranges defined but not used
925 ; Content-Range defined but not used
926 ; If-Range defined but not used
927 ; Range defined but not used
929 Appendix D. Change Log (to be removed by RFC Editor before publication)
931 D.1. Since RFC 2616
933 Extracted relevant partitions from [RFC2616].
935 D.2. Since draft-ietf-httpbis-p5-range-00
937 Closed issues:
939 o : "Cache
940 validators in 206 responses"
941 ()
943 o : "Normative and
944 Informative references"
946 o : "Normative up-
947 to-date references"
949 D.3. Since draft-ietf-httpbis-p5-range-01
951 Closed issues:
953 o : "Updating to
954 RFC4288"
956 Ongoing work on ABNF conversion
957 ():
959 o Add explicit references to BNF syntax and rules imported from
960 other parts of the specification.
962 D.4. Since draft-ietf-httpbis-p5-range-02
964 Ongoing work on IANA Message Header Field Registration
965 ():
967 o Reference RFC 3984, and update header field registrations for
968 headers defined in this document.
970 D.5. Since draft-ietf-httpbis-p5-range-03
972 None.
974 D.6. Since draft-ietf-httpbis-p5-range-04
976 Closed issues:
978 o : "multipart/
979 byteranges minimum number of parts"
981 Ongoing work on ABNF conversion
982 ():
984 o Use "/" instead of "|" for alternatives.
986 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
987 whitespace ("OWS") and required whitespace ("RWS").
989 o Rewrite ABNFs to spell out whitespace rules, factor out header
990 field value format definitions.
992 D.7. Since draft-ietf-httpbis-p5-range-05
994 Closed issues:
996 o : "State base
997 for *-byte-pos and suffix-length"
999 Ongoing work on Custom Ranges
1000 ():
1002 o Remove bias in favor of byte ranges; allow custom ranges in ABNF.
1004 Final work on ABNF conversion
1005 ():
1007 o Add appendix containing collected and expanded ABNF, reorganize
1008 ABNF introduction.
1010 D.8. Since draft-ietf-httpbis-p5-range-06
1012 Closed issues:
1014 o : "base for
1015 numeric protocol elements"
1017 D.9. Since draft-ietf-httpbis-p5-range-07
1019 Closed issues:
1021 o Fixed discrepancy in the If-Range definition about allowed
1022 validators.
1024 o : "multipart/
1025 byteranges for custom range units"
1027 o : "range unit
1028 missing from other-ranges-specifier in Range header"
1030 o : "move IANA
1031 registrations for optional status codes"
1033 D.10. Since draft-ietf-httpbis-p5-range-08
1035 No significant changes.
1037 D.11. Since draft-ietf-httpbis-p5-range-09
1039 No significant changes.
1041 D.12. Since draft-ietf-httpbis-p5-range-10
1043 Closed issues:
1045 o : "Clarify
1046 'Requested Variant'"
1048 o : "Clarify
1049 entity / representation / variant terminology"
1051 o : "consider
1052 removing the 'changes from 2068' sections"
1054 Ongoing work on Custom Ranges
1055 ():
1057 o Add IANA registry.
1059 D.13. Since draft-ietf-httpbis-p5-range-11
1061 Closed issues:
1063 o : "Caches can't
1064 be required to serve ranges"
1066 D.14. Since draft-ietf-httpbis-p5-range-12
1068 Closed issues:
1070 o : "Header
1071 Classification"
1073 D.15. Since draft-ietf-httpbis-p5-range-13
1075 Closed issues:
1077 o : "untangle
1078 ABNFs for header fields"
1080 Index
1082 2
1083 206 Partial Content (status code) 6
1085 4
1086 416 Requested Range Not Satisfiable (status code) 7
1088 A
1089 Accept-Ranges header field 8
1091 C
1092 Content-Range header field 8
1094 G
1095 Grammar
1096 Accept-Ranges 8
1097 acceptable-ranges 8
1098 byte-content-range-spec 8
1099 byte-range-resp-spec 8
1100 byte-range-set 12
1101 byte-range-spec 12
1102 byte-ranges-specifier 12
1103 bytes-unit 5
1104 Content-Range 8
1105 content-range-spec 8
1106 first-byte-pos 12
1107 If-Range 11
1108 instance-length 8
1109 last-byte-pos 12
1110 other-range-unit 5
1111 Range 13
1112 range-unit 5
1113 ranges-specifier 12
1114 suffix-byte-range-spec 12
1115 suffix-length 12
1117 H
1118 Header Fields
1119 Accept-Ranges 8
1120 Content-Range 8
1121 If-Range 10
1122 Range 11
1124 I
1125 If-Range header field 10
1127 M
1128 Media Type
1129 multipart/byteranges 16
1130 multipart/x-byteranges 19
1131 multipart/byteranges Media Type 16
1132 multipart/x-byteranges Media Type 19
1134 R
1135 Range header field 11
1137 S
1138 Status Codes
1139 206 Partial Content 6
1140 416 Requested Range Not Satisfiable 7
1142 Authors' Addresses
1144 Roy T. Fielding (editor)
1145 Adobe Systems Incorporated
1146 345 Park Ave
1147 San Jose, CA 95110
1148 USA
1150 EMail: fielding@gbiv.com
1151 URI: http://roy.gbiv.com/
1152 Jim Gettys
1153 Alcatel-Lucent Bell Labs
1154 21 Oak Knoll Road
1155 Carlisle, MA 01741
1156 USA
1158 EMail: jg@freedesktop.org
1159 URI: http://gettys.wordpress.com/
1161 Jeffrey C. Mogul
1162 Hewlett-Packard Company
1163 HP Labs, Large Scale Systems Group
1164 1501 Page Mill Road, MS 1177
1165 Palo Alto, CA 94304
1166 USA
1168 EMail: JeffMogul@acm.org
1170 Henrik Frystyk Nielsen
1171 Microsoft Corporation
1172 1 Microsoft Way
1173 Redmond, WA 98052
1174 USA
1176 EMail: henrikn@microsoft.com
1178 Larry Masinter
1179 Adobe Systems Incorporated
1180 345 Park Ave
1181 San Jose, CA 95110
1182 USA
1184 EMail: LMM@acm.org
1185 URI: http://larry.masinter.net/
1187 Paul J. Leach
1188 Microsoft Corporation
1189 1 Microsoft Way
1190 Redmond, WA 98052
1192 EMail: paulle@microsoft.com
1193 Tim Berners-Lee
1194 World Wide Web Consortium
1195 MIT Computer Science and Artificial Intelligence Laboratory
1196 The Stata Center, Building 32
1197 32 Vassar Street
1198 Cambridge, MA 02139
1199 USA
1201 EMail: timbl@w3.org
1202 URI: http://www.w3.org/People/Berners-Lee/
1204 Yves Lafon (editor)
1205 World Wide Web Consortium
1206 W3C / ERCIM
1207 2004, rte des Lucioles
1208 Sophia-Antipolis, AM 06902
1209 France
1211 EMail: ylafon@w3.org
1212 URI: http://www.raubacapeu.net/people/yves/
1214 Julian F. Reschke (editor)
1215 greenbytes GmbH
1216 Hafenweg 16
1217 Muenster, NW 48155
1218 Germany
1220 Phone: +49 251 2807760
1221 Fax: +49 251 2807761
1222 EMail: julian.reschke@greenbytes.de
1223 URI: http://greenbytes.de/tech/webdav/