idnits 2.17.1
draft-ietf-httpbis-p5-range-15.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 (July 11, 2011) is 4672 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-15
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p4-conditional-15
-- 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: January 12, 2012 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 July 11, 2011
22 HTTP/1.1, part 5: Range Requests and Partial Responses
23 draft-ietf-httpbis-p5-range-15
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.16.
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 January 12, 2012.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
96 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
97 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
98 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
99 1.2.2. ABNF Rules defined in other Parts of the
100 Specification . . . . . . . . . . . . . . . . . . . . 6
101 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
102 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
103 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
104 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
105 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8
106 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
107 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8
108 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
109 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
110 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
111 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12
112 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12
113 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14
114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
115 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
116 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
117 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
119 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
121 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
122 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
123 Appendix A. Internet Media Type multipart/byteranges . . . . . . 17
124 Appendix B. Compatibility with Previous Versions . . . . . . . . 20
125 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
126 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
127 Appendix D. Change Log (to be removed by RFC Editor before
128 publication) . . . . . . . . . . . . . . . . . . . . 22
129 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
130 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22
131 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
132 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
133 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
134 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
135 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
136 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
137 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
138 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
139 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
140 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
141 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
142 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
143 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
144 D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
146 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
148 1. Introduction
150 HTTP clients often encounter interrupted data transfers as a result
151 of cancelled requests or dropped connections. When a cache has
152 stored a partial representation, it is desirable to request the
153 remainder of that representation in a subsequent request rather than
154 transfer the entire representation. There are also a number of Web
155 applications that benefit from being able to request only a subset of
156 a larger representation, such as a single page of a very large
157 document or only part of an image to be rendered by a device with
158 limited local storage.
160 This document defines HTTP/1.1 range requests, partial responses, and
161 the multipart/byteranges media type. The protocol for range requests
162 is an OPTIONAL feature of HTTP, designed so resources or recipients
163 that do not implement this feature can respond as if it is a normal
164 GET request without impacting interoperability. Partial responses
165 are indicated by a distinct status code to not be mistaken for full
166 responses by intermediate caches that might not implement the
167 feature.
169 Although the HTTP range request mechanism is designed to allow for
170 extensible range types, this specification only defines requests for
171 byte ranges.
173 1.1. Requirements
175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
177 document are to be interpreted as described in [RFC2119].
179 An implementation is not compliant if it fails to satisfy one or more
180 of the "MUST" or "REQUIRED" level requirements for the protocols it
181 implements. An implementation that satisfies all the "MUST" or
182 "REQUIRED" level and all the "SHOULD" level requirements for its
183 protocols is said to be "unconditionally compliant"; one that
184 satisfies all the "MUST" level requirements but not all the "SHOULD"
185 level requirements for its protocols is said to be "conditionally
186 compliant".
188 1.2. Syntax Notation
190 This specification uses the ABNF syntax defined in Section 1.2 of
191 [Part1] (which extends the syntax defined in [RFC5234] with a list
192 rule). Appendix C shows the collected ABNF, with the list rule
193 expanded.
195 The following core rules are included by reference, as defined in
197 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
198 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
199 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
200 sequence of data), SP (space), VCHAR (any visible USASCII character),
201 and WSP (whitespace).
203 1.2.1. Core Rules
205 The core rules below are defined in Section 1.2.2 of [Part1]:
207 token =
208 OWS =
210 1.2.2. ABNF Rules defined in other Parts of the Specification
212 The ABNF rules below are defined in other parts:
214 HTTP-date =
216 entity-tag =
218 2. Range Units
220 HTTP/1.1 allows a client to request that only part (a range) of the
221 representation be included within the response. HTTP/1.1 uses range
222 units in the Range (Section 5.4) and Content-Range (Section 5.2)
223 header fields. A representation can be broken down into subranges
224 according to various structural units.
226 range-unit = bytes-unit / other-range-unit
227 bytes-unit = "bytes"
228 other-range-unit = token
230 HTTP/1.1 has been designed to allow implementations of applications
231 that do not depend on knowledge of ranges. The only range unit
232 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
233 as described in Section 2.1.
235 If a range unit is not understood in a request, a server MUST ignore
236 the whole Range header field (Section 5.4). If a range unit is not
237 understood in a response, an intermediary SHOULD pass the response to
238 the client; a client MUST fail.
240 2.1. Range Specifier Registry
242 The HTTP Range Specifier Registry defines the name space for the
243 range specifier names.
245 Registrations MUST include the following fields:
247 o Name
249 o Description
251 o Pointer to specification text
253 Values to be added to this name space are subject to IETF review
254 ([RFC5226], Section 4.1).
256 The registry itself is maintained at
257 .
259 3. Status Code Definitions
261 3.1. 206 Partial Content
263 The server has fulfilled the partial GET request for the resource.
264 The request MUST have included a Range header field (Section 5.4)
265 indicating the desired range, and MAY have included an If-Range
266 header field (Section 5.3) to make the request conditional.
268 The response MUST include the following header fields:
270 o Either a Content-Range header field (Section 5.2) indicating the
271 range included with this response, or a multipart/byteranges
272 Content-Type including Content-Range fields for each part. If a
273 Content-Length header field is present in the response, its value
274 MUST match the actual number of octets transmitted in the message-
275 body.
277 o Date
279 o Cache-Control, ETag, Expires, Content-Location, Last-Modified,
280 and/or Vary, if the header field would have been sent in a 200
281 response to the same request
283 If the 206 response is the result of an If-Range request, the
284 response SHOULD NOT include other representation header fields.
285 Otherwise, the response MUST include all of the representation header
286 fields that would have been returned with a 200 (OK) response to the
287 same request.
289 A cache MUST NOT combine a 206 response with other previously cached
290 content if the ETag or Last-Modified header fields do not match
291 exactly, see Section 4.
293 A cache that does not support the Range and Content-Range header
294 fields MUST NOT cache 206 (Partial Content) responses. Furthermore,
295 if a response uses a range unit that is not understood by the cache,
296 then it MUST NOT be cached either.
298 3.2. 416 Requested Range Not Satisfiable
300 A server SHOULD return a response with this status code if a request
301 included a Range header field (Section 5.4), and none of the ranges-
302 specifier values in this field overlap the current extent of the
303 selected resource, and the request did not include an If-Range header
304 field (Section 5.3). (For byte-ranges, this means that the first-
305 byte-pos of all of the byte-range-spec values were greater than the
306 current length of the selected resource.)
308 When this status code is returned for a byte-range request, the
309 response SHOULD include a Content-Range header field specifying the
310 current length of the representation (see Section 5.2). This
311 response MUST NOT use the multipart/byteranges content-type.
313 4. Combining Ranges
315 A response might transfer only a subrange of a representation, either
316 because the request included one or more Range specifications, or
317 because a connection closed prematurely. After several such
318 transfers, a cache might have received several ranges of the same
319 representation.
321 If a cache has a stored non-empty set of subranges for a
322 representation, and an incoming response transfers another subrange,
323 the cache MAY combine the new subrange with the existing set if both
324 the following conditions are met:
326 o Both the incoming response and the cache entry have a cache
327 validator.
329 o The two cache validators match using the strong comparison
330 function (see Section 2.2.2 of [Part4]).
332 If either requirement is not met, the cache MUST use only the most
333 recent partial response (based on the Date values transmitted with
334 every response, and using the incoming response if these values are
335 equal or missing), and MUST discard the other partial information.
337 5. Header Field Definitions
339 This section defines the syntax and semantics of HTTP/1.1 header
340 fields related to range requests and partial responses.
342 5.1. Accept-Ranges
344 The "Accept-Ranges" header field allows a resource to indicate its
345 acceptance of range requests.
347 Accept-Ranges = acceptable-ranges
348 acceptable-ranges = 1#range-unit / "none"
350 Origin servers that accept byte-range requests MAY send
352 Accept-Ranges: bytes
354 but are not required to do so. Clients MAY generate range requests
355 without having received this header field for the resource involved.
356 Range units are defined in Section 2.
358 Servers that do not accept any kind of range request for a resource
359 MAY send
361 Accept-Ranges: none
363 to advise the client not to attempt a range request.
365 5.2. Content-Range
367 The "Content-Range" header field is sent with a partial
368 representation to specify where in the full representation the
369 payload body is intended to be applied.
371 Range units are defined in Section 2.
373 Content-Range = content-range-spec
375 content-range-spec = byte-content-range-spec
376 / other-content-range-spec
377 byte-content-range-spec = bytes-unit SP
378 byte-range-resp-spec "/"
379 ( instance-length / "*" )
381 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
382 / "*"
384 instance-length = 1*DIGIT
386 other-content-range-spec = other-range-unit SP
387 other-range-resp-spec
388 other-range-resp-spec = *CHAR
390 The header field SHOULD indicate the total length of the full
391 representation, unless this length is unknown or difficult to
392 determine. The asterisk "*" character means that the instance-length
393 is unknown at the time when the response was generated.
395 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
396 range-resp-spec MUST only specify one range, and MUST contain
397 absolute byte positions for both the first and last byte of the
398 range.
400 A byte-content-range-spec with a byte-range-resp-spec whose last-
401 byte-pos value is less than its first-byte-pos value, or whose
402 instance-length value is less than or equal to its last-byte-pos
403 value, is invalid. The recipient of an invalid byte-content-range-
404 spec MUST ignore it and any content transferred along with it.
406 In the case of a byte range request: A server sending a response with
407 status code 416 (Requested range not satisfiable) SHOULD include a
408 Content-Range field with a byte-range-resp-spec of "*". The
409 instance-length specifies the current length of the selected
410 resource. A response with status code 206 (Partial Content) MUST NOT
411 include a Content-Range field with a byte-range-resp-spec of "*".
413 Examples of byte-content-range-spec values, assuming that the
414 representation contains a total of 1234 bytes:
416 o The first 500 bytes:
418 bytes 0-499/1234
420 o The second 500 bytes:
422 bytes 500-999/1234
424 o All except for the first 500 bytes:
426 bytes 500-1233/1234
428 o The last 500 bytes:
430 bytes 734-1233/1234
432 When an HTTP message includes the content of a single range (for
433 example, a response to a request for a single range, or to a request
434 for a set of ranges that overlap without any holes), this content is
435 transmitted with a Content-Range header field, and a Content-Length
436 header field showing the number of bytes actually transferred. For
437 example,
438 HTTP/1.1 206 Partial Content
439 Date: Wed, 15 Nov 1995 06:25:24 GMT
440 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
441 Content-Range: bytes 21010-47021/47022
442 Content-Length: 26012
443 Content-Type: image/gif
445 When an HTTP message includes the content of multiple ranges (for
446 example, a response to a request for multiple non-overlapping
447 ranges), these are transmitted as a multipart message. The multipart
448 media type used for this purpose is "multipart/byteranges" as defined
449 in Appendix A.
451 A response to a request for a single range MUST NOT be sent using the
452 multipart/byteranges media type. A response to a request for
453 multiple ranges, whose result is a single range, MAY be sent as a
454 multipart/byteranges media type with one part. A client that cannot
455 decode a multipart/byteranges message MUST NOT ask for multiple
456 ranges in a single request.
458 When a client requests multiple ranges in one request, the server
459 SHOULD return them in the order that they appeared in the request.
461 If the server ignores a byte-range-spec because it is syntactically
462 invalid, the server SHOULD treat the request as if the invalid Range
463 header field did not exist. (Normally, this means return a 200
464 response containing the full representation).
466 If the server receives a request (other than one including an If-
467 Range header field) with an unsatisfiable Range header field (that
468 is, all of whose byte-range-spec values have a first-byte-pos value
469 greater than the current length of the selected resource), it SHOULD
470 return a response code of 416 (Requested range not satisfiable)
471 (Section 3.2).
473 Note: Clients cannot depend on servers to send a 416 (Requested
474 range not satisfiable) response instead of a 200 (OK) response for
475 an unsatisfiable Range header field, since not all servers
476 implement this header field.
478 5.3. If-Range
480 If a client has a partial copy of a representation in its cache, and
481 wishes to have an up-to-date copy of the entire representation in its
482 cache, it could use the Range header field with a conditional GET
483 (using either or both of If-Unmodified-Since and If-Match.) However,
484 if the condition fails because the representation has been modified,
485 the client would then have to make a second request to obtain the
486 entire current representation.
488 The "If-Range" header field allows a client to "short-circuit" the
489 second request. Informally, its meaning is "if the representation is
490 unchanged, send me the part(s) that I am missing; otherwise, send me
491 the entire new representation".
493 If-Range = entity-tag / HTTP-date
495 Only a strong validator (Section 2.2.2 of [Part4]) is usable for
496 range retrieval, since otherwise the client might end up with an
497 internally inconsistent representation. Clients MUST NOT use weak
498 validators in range requests. A cache or origin server receiving a
499 conditional range request MUST use the strong comparison function to
500 evaluate the condition.
502 If the client has no entity-tag for a representation, but does have a
503 Last-Modified date, it MAY use that date in an If-Range header field.
504 (The server can distinguish between a valid HTTP-date and any form of
505 entity-tag by examining no more than two characters.) The If-Range
506 header field SHOULD only be used together with a Range header field,
507 and MUST be ignored if the request does not include a Range header
508 field, or if the server does not support the sub-range operation.
510 If a client wishes to perform a sub-range retrieval on a value for
511 which it has only a Last-Modified time and no opaque validator, it
512 MAY do this only if the Last-Modified time is strong in the sense
513 described in Section 2.1.2 of [Part4].
515 If the entity-tag given in the If-Range header field matches the
516 current cache validator for the representation, then the server
517 SHOULD provide the specified sub-range of the representation using a
518 206 (Partial Content) response. If the cache validator does not
519 match, then the server SHOULD return the entire representation using
520 a 200 (OK) response.
522 5.4. Range
524 5.4.1. Byte Ranges
526 Since all HTTP representations are transferred as sequences of bytes,
527 the concept of a byte range is meaningful for any HTTP
528 representation. (However, not all clients and servers need to
529 support byte-range operations.)
531 Byte range specifications in HTTP apply to the sequence of bytes in
532 the representation body (not necessarily the same as the message-
533 body).
535 A byte range operation MAY specify a single range of bytes, or a set
536 of ranges within a single representation.
538 byte-ranges-specifier = bytes-unit "=" byte-range-set
539 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
540 byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
541 first-byte-pos = 1*DIGIT
542 last-byte-pos = 1*DIGIT
544 The first-byte-pos value in a byte-range-spec gives the byte-offset
545 of the first byte in a range. The last-byte-pos value gives the
546 byte-offset of the last byte in the range; that is, the byte
547 positions specified are inclusive. Byte offsets start at zero.
549 If the last-byte-pos value is present, it MUST be greater than or
550 equal to the first-byte-pos in that byte-range-spec, or the byte-
551 range-spec is syntactically invalid. The recipient of a byte-range-
552 set that includes one or more syntactically invalid byte-range-spec
553 values MUST ignore the header field that includes that byte-range-
554 set.
556 If the last-byte-pos value is absent, or if the value is greater than
557 or equal to the current length of the representation body, last-byte-
558 pos is taken to be equal to one less than the current length of the
559 representation in bytes.
561 By its choice of last-byte-pos, a client can limit the number of
562 bytes retrieved without knowing the size of the representation.
564 suffix-byte-range-spec = "-" suffix-length
565 suffix-length = 1*DIGIT
567 A suffix-byte-range-spec is used to specify the suffix of the
568 representation body, of a length given by the suffix-length value.
569 (That is, this form specifies the last N bytes of a representation.)
570 If the representation is shorter than the specified suffix-length,
571 the entire representation is used.
573 If a syntactically valid byte-range-set includes at least one byte-
574 range-spec whose first-byte-pos is less than the current length of
575 the representation, or at least one suffix-byte-range-spec with a
576 non-zero suffix-length, then the byte-range-set is satisfiable.
577 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
578 set is unsatisfiable, the server SHOULD return a response with a 416
579 (Requested range not satisfiable) status code. Otherwise, the server
580 SHOULD return a response with a 206 (Partial Content) status code
581 containing the satisfiable ranges of the representation.
583 Examples of byte-ranges-specifier values (assuming a representation
584 of length 10000):
586 o The first 500 bytes (byte offsets 0-499, inclusive):
588 bytes=0-499
590 o The second 500 bytes (byte offsets 500-999, inclusive):
592 bytes=500-999
594 o The final 500 bytes (byte offsets 9500-9999, inclusive):
596 bytes=-500
598 Or:
600 bytes=9500-
602 o The first and last bytes only (bytes 0 and 9999):
604 bytes=0-0,-1
606 o Several legal but not canonical specifications of the second 500
607 bytes (byte offsets 500-999, inclusive):
609 bytes=500-600,601-999
610 bytes=500-700,601-999
612 5.4.2. Range Retrieval Requests
614 The "Range" header field defines the GET method (conditional or not)
615 to request one or more sub-ranges of the response representation
616 body, instead of the entire representation body.
618 Range = byte-ranges-specifier / other-ranges-specifier
619 other-ranges-specifier = other-range-unit "=" other-range-set
620 other-range-set = 1*CHAR
622 A server MAY ignore the Range header field. However, HTTP/1.1 origin
623 servers and intermediate caches ought to support byte ranges when
624 possible, since Range supports efficient recovery from partially
625 failed transfers, and supports efficient partial retrieval of large
626 representations.
628 If the server supports the Range header field and the specified range
629 or ranges are appropriate for the representation:
631 o The presence of a Range header field in an unconditional GET
632 modifies what is returned if the GET is otherwise successful. In
633 other words, the response carries a status code of 206 (Partial
634 Content) instead of 200 (OK).
636 o The presence of a Range header field in a conditional GET (a
637 request using one or both of If-Modified-Since and If-None-Match,
638 or one or both of If-Unmodified-Since and If-Match) modifies what
639 is returned if the GET is otherwise successful and the condition
640 is true. It does not affect the 304 (Not Modified) response
641 returned if the conditional is false.
643 In some cases, it might be more appropriate to use the If-Range
644 header field (see Section 5.3) in addition to the Range header field.
646 If a proxy that supports ranges receives a Range request, forwards
647 the request to an inbound server, and receives an entire
648 representation in reply, it MAY only return the requested range to
649 its client.
651 6. IANA Considerations
653 6.1. Status Code Registration
655 The HTTP Status Code Registry located at
656 shall be updated
657 with the registrations below:
659 +-------+---------------------------------+-------------+
660 | Value | Description | Reference |
661 +-------+---------------------------------+-------------+
662 | 206 | Partial Content | Section 3.1 |
663 | 416 | Requested Range Not Satisfiable | Section 3.2 |
664 +-------+---------------------------------+-------------+
666 6.2. Header Field Registration
668 The Message Header Field Registry located at shall be
670 updated with the permanent registrations below (see [RFC3864]):
672 +-------------------+----------+----------+-------------+
673 | Header Field Name | Protocol | Status | Reference |
674 +-------------------+----------+----------+-------------+
675 | Accept-Ranges | http | standard | Section 5.1 |
676 | Content-Range | http | standard | Section 5.2 |
677 | If-Range | http | standard | Section 5.3 |
678 | Range | http | standard | Section 5.4 |
679 +-------------------+----------+----------+-------------+
681 The change controller is: "IETF (iesg@ietf.org) - Internet
682 Engineering Task Force".
684 6.3. Range Specifier Registration
686 The registration procedure for HTTP Range Specifiers is defined by
687 Section 2.1 of this document.
689 The HTTP Range Specifier Registry shall be created at
690 and be
691 populated with the registrations below:
693 +----------------------+-------------------+----------------------+
694 | Range Specifier Name | Description | Reference |
695 +----------------------+-------------------+----------------------+
696 | bytes | a range of octets | (this specification) |
697 +----------------------+-------------------+----------------------+
699 The change controller is: "IETF (iesg@ietf.org) - Internet
700 Engineering Task Force".
702 7. Security Considerations
704 No additional security considerations have been identified beyond
705 those applicable to HTTP in general [Part1].
707 8. Acknowledgments
709 Most of the specification of ranges is based on work originally done
710 by Ari Luotonen and John Franks, with additional input from Steve
711 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
712 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
713 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
714 Rizzo, and Bill Weihl.
716 9. References
717 9.1. Normative References
719 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
720 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
721 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
722 and Message Parsing", draft-ietf-httpbis-p1-messaging-15
723 (work in progress), July 2011.
725 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
726 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
727 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
728 Requests", draft-ietf-httpbis-p4-conditional-15 (work in
729 progress), July 2011.
731 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
732 Extensions (MIME) Part Two: Media Types", RFC 2046,
733 November 1996.
735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
736 Requirement Levels", BCP 14, RFC 2119, March 1997.
738 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
739 Specifications: ABNF", STD 68, RFC 5234, January 2008.
741 9.2. Informative References
743 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
744 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
745 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
747 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
748 Procedures for Message Header Fields", BCP 90, RFC 3864,
749 September 2004.
751 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
752 Registration Procedures", BCP 13, RFC 4288, December 2005.
754 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
755 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
756 May 2008.
758 Appendix A. Internet Media Type multipart/byteranges
760 When an HTTP 206 (Partial Content) response message includes the
761 content of multiple ranges (a response to a request for multiple non-
762 overlapping ranges), these are transmitted as a multipart message-
763 body ([RFC2046], Section 5.1). The media type for this purpose is
764 called "multipart/byteranges". The following is to be registered
765 with IANA [RFC4288].
767 Note: Despite the name "multipart/byteranges" is not limited to
768 the byte ranges only.
770 The multipart/byteranges media type includes one or more parts, each
771 with its own Content-Type and Content-Range fields. The required
772 boundary parameter specifies the boundary string used to separate
773 each body-part.
775 Type name: multipart
777 Subtype name: byteranges
779 Required parameters: boundary
781 Optional parameters: none
783 Encoding considerations: only "7bit", "8bit", or "binary" are
784 permitted
786 Security considerations: none
788 Interoperability considerations: none
790 Published specification: This specification (see Appendix A).
792 Applications that use this media type:
794 Additional information:
796 Magic number(s): none
798 File extension(s): none
800 Macintosh file type code(s): none
802 Person and email address to contact for further information: See
803 Authors Section.
805 Intended usage: COMMON
807 Restrictions on usage: none
809 Author/Change controller: IESG
810 For example:
812 HTTP/1.1 206 Partial Content
813 Date: Wed, 15 Nov 1995 06:25:24 GMT
814 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
815 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
817 --THIS_STRING_SEPARATES
818 Content-type: application/pdf
819 Content-range: bytes 500-999/8000
821 ...the first range...
822 --THIS_STRING_SEPARATES
823 Content-type: application/pdf
824 Content-range: bytes 7000-7999/8000
826 ...the second range
827 --THIS_STRING_SEPARATES--
829 Other example:
831 HTTP/1.1 206 Partial Content
832 Date: Tue, 14 Nov 1995 06:25:24 GMT
833 Last-Modified: Tue, 14 July 04:58:08 GMT
834 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
836 --THIS_STRING_SEPARATES
837 Content-type: video/example
838 Content-range: exampleunit 1.2-4.3/25
840 ...the first range...
841 --THIS_STRING_SEPARATES
842 Content-type: video/example
843 Content-range: exampleunit 11.2-14.3/25
845 ...the second range
846 --THIS_STRING_SEPARATES--
848 Notes:
850 1. Additional CRLFs MAY precede the first boundary string in the
851 body.
853 2. Although [RFC2046] permits the boundary string to be quoted, some
854 existing implementations handle a quoted boundary string
855 incorrectly.
857 3. A number of browsers and servers were coded to an early draft of
858 the byteranges specification to use a media type of multipart/
859 x-byteranges, which is almost, but not quite compatible with the
860 version documented in HTTP/1.1.
862 Appendix B. Compatibility with Previous Versions
864 B.1. Changes from RFC 2616
866 Clarify that it is not ok to use a weak cache validator in a 206
867 response. (Section 3.1)
869 Change ABNF productions for header fields to only define the field
870 value. (Section 5)
872 Clarify that multipart/byteranges can consist of a single part.
873 (Appendix A)
875 Appendix C. Collected ABNF
876 Accept-Ranges = acceptable-ranges
878 Content-Range = content-range-spec
880 HTTP-date =
882 If-Range = entity-tag / HTTP-date
884 OWS =
886 Range = byte-ranges-specifier / other-ranges-specifier
888 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
889 range-unit ] ) ) / "none"
891 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
892 instance-length / "*" )
893 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
894 byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
895 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
896 suffix-byte-range-spec ] ) )
897 byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
898 byte-ranges-specifier = bytes-unit "=" byte-range-set
899 bytes-unit = "bytes"
901 content-range-spec = byte-content-range-spec /
902 other-content-range-spec
904 entity-tag =
906 first-byte-pos = 1*DIGIT
908 instance-length = 1*DIGIT
910 last-byte-pos = 1*DIGIT
912 other-content-range-spec = other-range-unit SP other-range-resp-spec
913 other-range-resp-spec = *CHAR
914 other-range-set = 1*CHAR
915 other-range-unit = token
916 other-ranges-specifier = other-range-unit "=" other-range-set
918 range-unit = bytes-unit / other-range-unit
920 suffix-byte-range-spec = "-" suffix-length
921 suffix-length = 1*DIGIT
923 token =
924 ABNF diagnostics:
926 ; Accept-Ranges defined but not used
927 ; Content-Range defined but not used
928 ; If-Range defined but not used
929 ; Range defined but not used
931 Appendix D. Change Log (to be removed by RFC Editor before publication)
933 D.1. Since RFC 2616
935 Extracted relevant partitions from [RFC2616].
937 D.2. Since draft-ietf-httpbis-p5-range-00
939 Closed issues:
941 o : "Cache
942 validators in 206 responses"
943 ()
945 o : "Normative and
946 Informative references"
948 o : "Normative up-
949 to-date references"
951 D.3. Since draft-ietf-httpbis-p5-range-01
953 Closed issues:
955 o : "Updating to
956 RFC4288"
958 Ongoing work on ABNF conversion
959 ():
961 o Add explicit references to BNF syntax and rules imported from
962 other parts of the specification.
964 D.4. Since draft-ietf-httpbis-p5-range-02
966 Ongoing work on IANA Message Header Field Registration
967 ():
969 o Reference RFC 3984, and update header field registrations for
970 headers defined in this document.
972 D.5. Since draft-ietf-httpbis-p5-range-03
974 None.
976 D.6. Since draft-ietf-httpbis-p5-range-04
978 Closed issues:
980 o : "multipart/
981 byteranges minimum number of parts"
983 Ongoing work on ABNF conversion
984 ():
986 o Use "/" instead of "|" for alternatives.
988 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
989 whitespace ("OWS") and required whitespace ("RWS").
991 o Rewrite ABNFs to spell out whitespace rules, factor out header
992 field value format definitions.
994 D.7. Since draft-ietf-httpbis-p5-range-05
996 Closed issues:
998 o : "State base
999 for *-byte-pos and suffix-length"
1001 Ongoing work on Custom Ranges
1002 ():
1004 o Remove bias in favor of byte ranges; allow custom ranges in ABNF.
1006 Final work on ABNF conversion
1007 ():
1009 o Add appendix containing collected and expanded ABNF, reorganize
1010 ABNF introduction.
1012 D.8. Since draft-ietf-httpbis-p5-range-06
1014 Closed issues:
1016 o : "base for
1017 numeric protocol elements"
1019 D.9. Since draft-ietf-httpbis-p5-range-07
1021 Closed issues:
1023 o Fixed discrepancy in the If-Range definition about allowed
1024 validators.
1026 o : "multipart/
1027 byteranges for custom range units"
1029 o : "range unit
1030 missing from other-ranges-specifier in Range header"
1032 o : "move IANA
1033 registrations for optional status codes"
1035 D.10. Since draft-ietf-httpbis-p5-range-08
1037 No significant changes.
1039 D.11. Since draft-ietf-httpbis-p5-range-09
1041 No significant changes.
1043 D.12. Since draft-ietf-httpbis-p5-range-10
1045 Closed issues:
1047 o : "Clarify
1048 'Requested Variant'"
1050 o : "Clarify
1051 entity / representation / variant terminology"
1053 o : "consider
1054 removing the 'changes from 2068' sections"
1056 Ongoing work on Custom Ranges
1057 ():
1059 o Add IANA registry.
1061 D.13. Since draft-ietf-httpbis-p5-range-11
1063 Closed issues:
1065 o : "Caches can't
1066 be required to serve ranges"
1068 D.14. Since draft-ietf-httpbis-p5-range-12
1070 Closed issues:
1072 o : "Header
1073 Classification"
1075 D.15. Since draft-ietf-httpbis-p5-range-13
1077 Closed issues:
1079 o : "untangle
1080 ABNFs for header fields"
1082 D.16. Since draft-ietf-httpbis-p5-range-14
1084 None.
1086 Index
1088 2
1089 206 Partial Content (status code) 7
1091 4
1092 416 Requested Range Not Satisfiable (status code) 8
1094 A
1095 Accept-Ranges header field 9
1097 C
1098 Content-Range header field 9
1100 G
1101 Grammar
1102 Accept-Ranges 9
1103 acceptable-ranges 9
1104 byte-content-range-spec 9
1105 byte-range-resp-spec 9
1106 byte-range-set 13
1107 byte-range-spec 13
1108 byte-ranges-specifier 13
1109 bytes-unit 6
1110 Content-Range 9
1111 content-range-spec 9
1112 first-byte-pos 13
1113 If-Range 12
1114 instance-length 9
1115 last-byte-pos 13
1116 other-range-unit 6
1117 Range 14
1118 range-unit 6
1119 ranges-specifier 13
1120 suffix-byte-range-spec 13
1121 suffix-length 13
1123 H
1124 Header Fields
1125 Accept-Ranges 9
1126 Content-Range 9
1127 If-Range 11
1128 Range 12
1130 I
1131 If-Range header field 11
1133 M
1134 Media Type
1135 multipart/byteranges 17
1136 multipart/x-byteranges 20
1137 multipart/byteranges Media Type 17
1138 multipart/x-byteranges Media Type 20
1140 R
1141 Range header field 12
1143 S
1144 Status Codes
1145 206 Partial Content 7
1146 416 Requested Range Not Satisfiable 8
1148 Authors' Addresses
1150 Roy T. Fielding (editor)
1151 Adobe Systems Incorporated
1152 345 Park Ave
1153 San Jose, CA 95110
1154 USA
1156 EMail: fielding@gbiv.com
1157 URI: http://roy.gbiv.com/
1158 Jim Gettys
1159 Alcatel-Lucent Bell Labs
1160 21 Oak Knoll Road
1161 Carlisle, MA 01741
1162 USA
1164 EMail: jg@freedesktop.org
1165 URI: http://gettys.wordpress.com/
1167 Jeffrey C. Mogul
1168 Hewlett-Packard Company
1169 HP Labs, Large Scale Systems Group
1170 1501 Page Mill Road, MS 1177
1171 Palo Alto, CA 94304
1172 USA
1174 EMail: JeffMogul@acm.org
1176 Henrik Frystyk Nielsen
1177 Microsoft Corporation
1178 1 Microsoft Way
1179 Redmond, WA 98052
1180 USA
1182 EMail: henrikn@microsoft.com
1184 Larry Masinter
1185 Adobe Systems Incorporated
1186 345 Park Ave
1187 San Jose, CA 95110
1188 USA
1190 EMail: LMM@acm.org
1191 URI: http://larry.masinter.net/
1193 Paul J. Leach
1194 Microsoft Corporation
1195 1 Microsoft Way
1196 Redmond, WA 98052
1198 EMail: paulle@microsoft.com
1199 Tim Berners-Lee
1200 World Wide Web Consortium
1201 MIT Computer Science and Artificial Intelligence Laboratory
1202 The Stata Center, Building 32
1203 32 Vassar Street
1204 Cambridge, MA 02139
1205 USA
1207 EMail: timbl@w3.org
1208 URI: http://www.w3.org/People/Berners-Lee/
1210 Yves Lafon (editor)
1211 World Wide Web Consortium
1212 W3C / ERCIM
1213 2004, rte des Lucioles
1214 Sophia-Antipolis, AM 06902
1215 France
1217 EMail: ylafon@w3.org
1218 URI: http://www.raubacapeu.net/people/yves/
1220 Julian F. Reschke (editor)
1221 greenbytes GmbH
1222 Hafenweg 16
1223 Muenster, NW 48155
1224 Germany
1226 Phone: +49 251 2807760
1227 Fax: +49 251 2807761
1228 EMail: julian.reschke@greenbytes.de
1229 URI: http://greenbytes.de/tech/webdav/