idnits 2.17.1
draft-ietf-httpbis-p5-range-16.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 (August 24, 2011) is 4621 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-16
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p4-conditional-16
-- 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: February 25, 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 August 24, 2011
22 HTTP/1.1, part 5: Range Requests and Partial Responses
23 draft-ietf-httpbis-p5-range-16
25 Abstract
27 The Hypertext Transfer Protocol (HTTP) is an application-level
28 protocol for distributed, collaborative, hypertext 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.
34 Part 5 defines range-specific requests and the rules for constructing
35 and combining responses to those requests.
37 Editorial Note (To be removed by RFC Editor)
39 Discussion of this draft should take place on the HTTPBIS working
40 group mailing list (ietf-http-wg@w3.org), which is archived at
41 .
43 The current issues list is at
44 and related
45 documents (including fancy diffs) can be found at
46 .
48 The changes in this draft are summarized in Appendix D.17.
50 Status of This Memo
52 This Internet-Draft is submitted in full conformance with the
53 provisions of BCP 78 and BCP 79.
55 Internet-Drafts are working documents of the Internet Engineering
56 Task Force (IETF). Note that other groups may also distribute
57 working documents as Internet-Drafts. The list of current Internet-
58 Drafts is at http://datatracker.ietf.org/drafts/current/.
60 Internet-Drafts are draft documents valid for a maximum of six months
61 and may be updated, replaced, or obsoleted by other documents at any
62 time. It is inappropriate to use Internet-Drafts as reference
63 material or to cite them other than as "work in progress."
65 This Internet-Draft will expire on February 25, 2012.
67 Copyright Notice
69 Copyright (c) 2011 IETF Trust and the persons identified as the
70 document authors. All rights reserved.
72 This document is subject to BCP 78 and the IETF Trust's Legal
73 Provisions Relating to IETF Documents
74 (http://trustee.ietf.org/license-info) in effect on the date of
75 publication of this document. Please review these documents
76 carefully, as they describe your rights and restrictions with respect
77 to this document. Code Components extracted from this document must
78 include Simplified BSD License text as described in Section 4.e of
79 the Trust Legal Provisions and are provided without warranty as
80 described in the Simplified BSD License.
82 This document may contain material from IETF Documents or IETF
83 Contributions published or made publicly available before November
84 10, 2008. The person(s) controlling the copyright in some of this
85 material may not have granted the IETF Trust the right to allow
86 modifications of such material outside the IETF Standards Process.
87 Without obtaining an adequate license from the person(s) controlling
88 the copyright in such materials, this document may not be modified
89 outside the IETF Standards Process, and derivative works of it may
90 not be created outside the IETF Standards Process, except to format
91 it for publication as an RFC or to translate it into languages other
92 than English.
94 Table of Contents
96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
97 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
98 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
99 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
100 1.2.2. ABNF Rules defined in other Parts of the
101 Specification . . . . . . . . . . . . . . . . . . . . 6
102 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
103 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
104 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
105 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
106 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7
107 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
108 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
109 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
110 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
111 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12
112 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13
113 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13
114 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15
115 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
116 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
117 6.2. Header Field Registration . . . . . . . . . . . . . . . . 16
118 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
119 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
120 7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17
121 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
122 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
123 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
124 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
125 Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
126 Appendix B. Compatibility with Previous Versions . . . . . . . . 20
127 B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
128 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
129 Appendix D. Change Log (to be removed by RFC Editor before
130 publication) . . . . . . . . . . . . . . . . . . . . 22
131 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
132 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22
133 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
134 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
135 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23
136 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23
137 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23
138 D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
139 D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24
140 D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24
141 D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24
142 D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24
143 D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24
144 D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25
145 D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25
146 D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25
147 D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25
148 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
150 1. Introduction
152 HTTP clients often encounter interrupted data transfers as a result
153 of cancelled requests or dropped connections. When a client has
154 stored a partial representation, it is desirable to request the
155 remainder of that representation in a subsequent request rather than
156 transfer the entire representation. There are also a number of Web
157 applications that benefit from being able to request only a subset of
158 a larger representation, such as a single page of a very large
159 document or only part of an image to be rendered by a device with
160 limited local storage.
162 This document defines HTTP/1.1 range requests, partial responses, and
163 the multipart/byteranges media type. The protocol for range requests
164 is an OPTIONAL feature of HTTP, designed so resources or recipients
165 that do not implement this feature can respond as if it is a normal
166 GET request without impacting interoperability. Partial responses
167 are indicated by a distinct status code to not be mistaken for full
168 responses by intermediate caches that might not implement the
169 feature.
171 Although the HTTP range request mechanism is designed to allow for
172 extensible range types, this specification only defines requests for
173 byte ranges.
175 1.1. Requirements
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179 document are to be interpreted as described in [RFC2119].
181 An implementation is not compliant if it fails to satisfy one or more
182 of the "MUST" or "REQUIRED" level requirements for the protocols it
183 implements. An implementation that satisfies all the "MUST" or
184 "REQUIRED" level and all the "SHOULD" level requirements for its
185 protocols is said to be "unconditionally compliant"; one that
186 satisfies all the "MUST" level requirements but not all the "SHOULD"
187 level requirements for its protocols is said to be "conditionally
188 compliant".
190 1.2. Syntax Notation
192 This specification uses the ABNF syntax defined in Section 1.2 of
193 [Part1] (which extends the syntax defined in [RFC5234] with a list
194 rule). Appendix C shows the collected ABNF, with the list rule
195 expanded.
197 The following core rules are included by reference, as defined in
199 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
200 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
201 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
202 sequence of data), SP (space), VCHAR (any visible USASCII character),
203 and WSP (whitespace).
205 1.2.1. Core Rules
207 The core rules below are defined in [Part1]:
209 OWS =
210 token =
211 HTTP-date =
213 1.2.2. ABNF Rules defined in other Parts of the Specification
215 The ABNF rules below are defined in other parts:
217 entity-tag =
219 2. Range Units
221 HTTP/1.1 allows a client to request that only part (a range) of the
222 representation be included within the response. HTTP/1.1 uses range
223 units in the Range (Section 5.4) and Content-Range (Section 5.2)
224 header fields. A representation can be broken down into subranges
225 according to various structural units.
227 range-unit = bytes-unit / other-range-unit
228 bytes-unit = "bytes"
229 other-range-unit = token
231 HTTP/1.1 has been designed to allow implementations of applications
232 that do not depend on knowledge of ranges. The only range unit
233 defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
234 as described in Section 2.1.
236 If a range unit is not understood in a request, a server MUST ignore
237 the whole Range header field (Section 5.4). If a range unit is not
238 understood in a response, an intermediary SHOULD pass the response to
239 the client; a client MUST fail.
241 2.1. Range Specifier Registry
243 The HTTP Range Specifier Registry defines the name space for the
244 range specifier names.
246 Registrations MUST include the following fields:
248 o Name
250 o Description
252 o Pointer to specification text
254 Values to be added to this name space are subject to IETF review
255 ([RFC5226], Section 4.1).
257 The registry itself is maintained at
258 .
260 3. Status Code Definitions
262 3.1. 206 Partial Content
264 The server has fulfilled the partial GET request for the resource.
265 The request MUST have included a Range header field (Section 5.4)
266 indicating the desired range, and MAY have included an If-Range
267 header field (Section 5.3) to make the request conditional.
269 The response MUST include the following header fields:
271 o Either a Content-Range header field (Section 5.2) indicating the
272 range included with this response, or a multipart/byteranges
273 Content-Type including Content-Range fields for each part. If a
274 Content-Length header field is present in the response, its value
275 MUST match the actual number of octets transmitted in the message-
276 body.
278 o Date
280 o Cache-Control, ETag, Expires, Content-Location, Last-Modified,
281 and/or Vary, if the header field would have been sent in a 200
282 response to the same request
284 If the 206 response is the result of an If-Range request, the
285 response SHOULD NOT include other representation header fields.
286 Otherwise, the response MUST include all of the representation header
287 fields that would have been returned with a 200 (OK) response to the
288 same request.
290 3.2. 416 Requested Range Not Satisfiable
292 A server SHOULD return a response with this status code if a request
293 included a Range header field (Section 5.4), and none of the ranges-
294 specifier values in this field overlap the current extent of the
295 selected resource, and the request did not include an If-Range header
296 field (Section 5.3). (For byte-ranges, this means that the first-
297 byte-pos of all of the byte-range-spec values were greater than the
298 current length of the selected resource.)
300 When this status code is returned for a byte-range request, the
301 response SHOULD include a Content-Range header field specifying the
302 current length of the representation (see Section 5.2). This
303 response MUST NOT use the multipart/byteranges content-type.
305 4. Combining Ranges
307 A response might transfer only a subrange of a representation if the
308 connection closed prematurely or if the request used one or more
309 Range specifications. After several such transfers, a client might
310 have received several ranges of the same representation. These
311 ranges can only be safely combined if they all have in common the
312 same strong validator, where "strong validator" is defined to be
313 either an entity-tag that is not marked as weak (Section 2.3 of
314 [Part4]) or, if no entity-tag is provided, a Last-Modified value that
315 is strong in the sense defined by Section 2.2.2 of [Part4].
317 When a client receives an incomplete 200 (OK) or 206 (Partial
318 Content) response and already has one or more stored responses for
319 the same method and effective request URI, all of the stored
320 responses with the same strong validator MAY be combined with the
321 partial content in this new response. If none of the stored
322 responses contain the same strong validator, then this new response
323 corresponds to a new representation and MUST NOT be combined with the
324 existing stored responses.
326 If the new response is an incomplete 200 (OK) response, then the
327 header fields of that new response are used for any combined response
328 and replace those of the matching stored responses.
330 If the new response is a 206 (Partial Content) response and at least
331 one of the matching stored responses is a 200 (OK), then the combined
332 response header fields consist of the most recent 200 response's
333 header fields. If all of the matching stored responses are 206
334 responses, then the stored response with the most header fields is
335 used as the source of header fields for the combined response, except
336 that the client MUST use other header fields provided in the new
337 response, aside from Content-Range, to replace all instances of the
338 corresponding header fields in the stored response.
340 The combined response message-body consists of the union of partial
341 content ranges in the new response and each of the selected
342 responses. If the union consists of the entire range of the
343 representation, then the combined response MUST be recorded as a
344 complete 200 (OK) response with a Content-Length header field that
345 reflects the complete length. Otherwise, the combined response(s)
346 MUST include a Content-Range header field describing the included
347 range(s) and be recorded as incomplete. If the union consists of a
348 discontinuous range of the representation, then the client MAY store
349 it as either a multipart range response or as multiple 206 responses
350 with one continuous range each.
352 5. Header Field Definitions
354 This section defines the syntax and semantics of HTTP/1.1 header
355 fields related to range requests and partial responses.
357 5.1. Accept-Ranges
359 The "Accept-Ranges" header field allows a resource to indicate its
360 acceptance of range requests.
362 Accept-Ranges = acceptable-ranges
363 acceptable-ranges = 1#range-unit / "none"
365 Origin servers that accept byte-range requests MAY send
367 Accept-Ranges: bytes
369 but are not required to do so. Clients MAY generate range requests
370 without having received this header field for the resource involved.
371 Range units are defined in Section 2.
373 Servers that do not accept any kind of range request for a resource
374 MAY send
376 Accept-Ranges: none
378 to advise the client not to attempt a range request.
380 5.2. Content-Range
382 The "Content-Range" header field is sent with a partial
383 representation to specify where in the full representation the
384 payload body is intended to be applied.
386 Range units are defined in Section 2.
388 Content-Range = byte-content-range-spec
389 / other-content-range-spec
391 byte-content-range-spec = bytes-unit SP
392 byte-range-resp-spec "/"
393 ( instance-length / "*" )
395 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
396 / "*"
398 instance-length = 1*DIGIT
400 other-content-range-spec = other-range-unit SP
401 other-range-resp-spec
402 other-range-resp-spec = *CHAR
404 The header field SHOULD indicate the total length of the full
405 representation, unless this length is unknown or difficult to
406 determine. The asterisk "*" character means that the instance-length
407 is unknown at the time when the response was generated.
409 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
410 range-resp-spec MUST only specify one range, and MUST contain
411 absolute byte positions for both the first and last byte of the
412 range.
414 A byte-content-range-spec with a byte-range-resp-spec whose last-
415 byte-pos value is less than its first-byte-pos value, or whose
416 instance-length value is less than or equal to its last-byte-pos
417 value, is invalid. The recipient of an invalid byte-content-range-
418 spec MUST ignore it and any content transferred along with it.
420 In the case of a byte range request: A server sending a response with
421 status code 416 (Requested range not satisfiable) SHOULD include a
422 Content-Range field with a byte-range-resp-spec of "*". The
423 instance-length specifies the current length of the selected
424 resource. A response with status code 206 (Partial Content) MUST NOT
425 include a Content-Range field with a byte-range-resp-spec of "*".
427 Examples of byte-content-range-spec values, assuming that the
428 representation contains a total of 1234 bytes:
430 o The first 500 bytes:
432 bytes 0-499/1234
434 o The second 500 bytes:
436 bytes 500-999/1234
438 o All except for the first 500 bytes:
440 bytes 500-1233/1234
442 o The last 500 bytes:
444 bytes 734-1233/1234
446 When an HTTP message includes the content of a single range (for
447 example, a response to a request for a single range, or to a request
448 for a set of ranges that overlap without any holes), this content is
449 transmitted with a Content-Range header field, and a Content-Length
450 header field showing the number of bytes actually transferred. For
451 example,
453 HTTP/1.1 206 Partial Content
454 Date: Wed, 15 Nov 1995 06:25:24 GMT
455 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
456 Content-Range: bytes 21010-47021/47022
457 Content-Length: 26012
458 Content-Type: image/gif
460 When an HTTP message includes the content of multiple ranges (for
461 example, a response to a request for multiple non-overlapping
462 ranges), these are transmitted as a multipart message. The multipart
463 media type used for this purpose is "multipart/byteranges" as defined
464 in Appendix A.
466 A response to a request for a single range MUST NOT be sent using the
467 multipart/byteranges media type. A response to a request for
468 multiple ranges, whose result is a single range, MAY be sent as a
469 multipart/byteranges media type with one part. A client that cannot
470 decode a multipart/byteranges message MUST NOT ask for multiple
471 ranges in a single request.
473 When a client requests multiple ranges in one request, the server
474 SHOULD return them in the order that they appeared in the request.
476 If the server ignores a byte-range-spec because it is syntactically
477 invalid, the server SHOULD treat the request as if the invalid Range
478 header field did not exist. (Normally, this means return a 200
479 response containing the full representation).
481 If the server receives a request (other than one including an If-
482 Range header field) with an unsatisfiable Range header field (that
483 is, all of whose byte-range-spec values have a first-byte-pos value
484 greater than the current length of the selected resource), it SHOULD
485 return a response code of 416 (Requested range not satisfiable)
486 (Section 3.2).
488 Note: Clients cannot depend on servers to send a 416 (Requested
489 range not satisfiable) response instead of a 200 (OK) response for
490 an unsatisfiable Range header field, since not all servers
491 implement this header field.
493 5.3. If-Range
495 If a client has a partial copy of a representation and wishes to have
496 an up-to-date copy of the entire representation, it could use the
497 Range header field with a conditional GET (using either or both of
498 If-Unmodified-Since and If-Match.) However, if the condition fails
499 because the representation has been modified, the client would then
500 have to make a second request to obtain the entire current
501 representation.
503 The "If-Range" header field allows a client to "short-circuit" the
504 second request. Informally, its meaning is "if the representation is
505 unchanged, send me the part(s) that I am missing; otherwise, send me
506 the entire new representation".
508 If-Range = entity-tag / HTTP-date
510 Clients MUST NOT use an entity-tag marked as weak in an If-Range
511 field value and MUST NOT use a Last-Modified date in an If-Range
512 field value unless it has no entity-tag for the representation and
513 the Last-Modified date it does have for the representation is strong
514 in the sense defined by Section 2.2.2 of [Part4].
516 A server that evaluates a conditional range request that is
517 applicable to one of its representations MUST evaluate the condition
518 as false if the entity-tag used as a validator is marked as weak or,
519 when an HTTP-date is used as the validator, if the date value is not
520 strong in the sense defined by Section 2.2.2 of [Part4]. (A server
521 can distinguish between a valid HTTP-date and any form of entity-tag
522 by examining the first two characters.)
524 The If-Range header field SHOULD only be sent by clients together
525 with a Range header field. The If-Range header field MUST be ignored
526 if it is received in a request that does not include a Range header
527 field. The If-Range header field MUST be ignored by a server that
528 does not support the sub-range operation.
530 If the validator given in the If-Range header field matches the
531 current validator for the selected representation of the target
532 resource, then the server SHOULD send the specified sub-range of the
533 representation using a 206 (Partial Content) response. If the
534 validator does not match, then the server SHOULD send the entire
535 representation using a 200 (OK) response.
537 5.4. Range
539 5.4.1. Byte Ranges
541 Since all HTTP representations are transferred as sequences of bytes,
542 the concept of a byte range is meaningful for any HTTP
543 representation. (However, not all clients and servers need to
544 support byte-range operations.)
546 Byte range specifications in HTTP apply to the sequence of bytes in
547 the representation body (not necessarily the same as the message-
548 body).
550 A byte range operation MAY specify a single range of bytes, or a set
551 of ranges within a single representation.
553 byte-ranges-specifier = bytes-unit "=" byte-range-set
554 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
555 byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
556 first-byte-pos = 1*DIGIT
557 last-byte-pos = 1*DIGIT
559 The first-byte-pos value in a byte-range-spec gives the byte-offset
560 of the first byte in a range. The last-byte-pos value gives the
561 byte-offset of the last byte in the range; that is, the byte
562 positions specified are inclusive. Byte offsets start at zero.
564 If the last-byte-pos value is present, it MUST be greater than or
565 equal to the first-byte-pos in that byte-range-spec, or the byte-
566 range-spec is syntactically invalid. The recipient of a byte-range-
567 set that includes one or more syntactically invalid byte-range-spec
568 values MUST ignore the header field that includes that byte-range-
569 set.
571 If the last-byte-pos value is absent, or if the value is greater than
572 or equal to the current length of the representation body, last-byte-
573 pos is taken to be equal to one less than the current length of the
574 representation in bytes.
576 By its choice of last-byte-pos, a client can limit the number of
577 bytes retrieved without knowing the size of the representation.
579 suffix-byte-range-spec = "-" suffix-length
580 suffix-length = 1*DIGIT
582 A suffix-byte-range-spec is used to specify the suffix of the
583 representation body, of a length given by the suffix-length value.
584 (That is, this form specifies the last N bytes of a representation.)
585 If the representation is shorter than the specified suffix-length,
586 the entire representation is used.
588 If a syntactically valid byte-range-set includes at least one byte-
589 range-spec whose first-byte-pos is less than the current length of
590 the representation, or at least one suffix-byte-range-spec with a
591 non-zero suffix-length, then the byte-range-set is satisfiable.
592 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
593 set is unsatisfiable, the server SHOULD return a response with a 416
594 (Requested range not satisfiable) status code. Otherwise, the server
595 SHOULD return a response with a 206 (Partial Content) status code
596 containing the satisfiable ranges of the representation.
598 Examples of byte-ranges-specifier values (assuming a representation
599 of length 10000):
601 o The first 500 bytes (byte offsets 0-499, inclusive):
603 bytes=0-499
605 o The second 500 bytes (byte offsets 500-999, inclusive):
607 bytes=500-999
609 o The final 500 bytes (byte offsets 9500-9999, inclusive):
611 bytes=-500
613 Or:
615 bytes=9500-
617 o The first and last bytes only (bytes 0 and 9999):
619 bytes=0-0,-1
621 o Several legal but not canonical specifications of the second 500
622 bytes (byte offsets 500-999, inclusive):
624 bytes=500-600,601-999
625 bytes=500-700,601-999
627 5.4.2. Range Retrieval Requests
629 The "Range" header field defines the GET method (conditional or not)
630 to request one or more sub-ranges of the response representation
631 body, instead of the entire representation body.
633 Range = byte-ranges-specifier / other-ranges-specifier
634 other-ranges-specifier = other-range-unit "=" other-range-set
635 other-range-set = 1*CHAR
637 A server MAY ignore the Range header field. However, origin servers
638 and intermediate caches ought to support byte ranges when possible,
639 since Range supports efficient recovery from partially failed
640 transfers, and supports efficient partial retrieval of large
641 representations.
643 If the server supports the Range header field and the specified range
644 or ranges are appropriate for the representation:
646 o The presence of a Range header field in an unconditional GET
647 modifies what is returned if the GET is otherwise successful. In
648 other words, the response carries a status code of 206 (Partial
649 Content) instead of 200 (OK).
651 o The presence of a Range header field in a conditional GET (a
652 request using one or both of If-Modified-Since and If-None-Match,
653 or one or both of If-Unmodified-Since and If-Match) modifies what
654 is returned if the GET is otherwise successful and the condition
655 is true. It does not affect the 304 (Not Modified) response
656 returned if the conditional is false.
658 In some cases, it might be more appropriate to use the If-Range
659 header field (see Section 5.3) in addition to the Range header field.
661 If a proxy that supports ranges receives a Range request, forwards
662 the request to an inbound server, and receives an entire
663 representation in reply, it MAY only return the requested range to
664 its client.
666 6. IANA Considerations
668 6.1. Status Code Registration
670 The HTTP Status Code Registry located at
671 shall be updated
672 with the registrations below:
674 +-------+---------------------------------+-------------+
675 | Value | Description | Reference |
676 +-------+---------------------------------+-------------+
677 | 206 | Partial Content | Section 3.1 |
678 | 416 | Requested Range Not Satisfiable | Section 3.2 |
679 +-------+---------------------------------+-------------+
681 6.2. Header Field Registration
683 The Message Header Field Registry located at shall be
685 updated with the permanent registrations below (see [RFC3864]):
687 +-------------------+----------+----------+-------------+
688 | Header Field Name | Protocol | Status | Reference |
689 +-------------------+----------+----------+-------------+
690 | Accept-Ranges | http | standard | Section 5.1 |
691 | Content-Range | http | standard | Section 5.2 |
692 | If-Range | http | standard | Section 5.3 |
693 | Range | http | standard | Section 5.4 |
694 +-------------------+----------+----------+-------------+
696 The change controller is: "IETF (iesg@ietf.org) - Internet
697 Engineering Task Force".
699 6.3. Range Specifier Registration
701 The registration procedure for HTTP Range Specifiers is defined by
702 Section 2.1 of this document.
704 The HTTP Range Specifier Registry shall be created at
705 and be
706 populated with the registrations below:
708 +----------------------+-------------------+----------------------+
709 | Range Specifier Name | Description | Reference |
710 +----------------------+-------------------+----------------------+
711 | bytes | a range of octets | (this specification) |
712 +----------------------+-------------------+----------------------+
714 The change controller is: "IETF (iesg@ietf.org) - Internet
715 Engineering Task Force".
717 7. Security Considerations
719 This section is meant to inform application developers, information
720 providers, and users of the security limitations in HTTP/1.1 as
721 described by this document. The discussion does not include
722 definitive solutions to the problems revealed, though it does make
723 some suggestions for reducing security risks.
725 7.1. Overlapping Ranges
727 Range requests containing overlapping ranges may lead to the
728 situation where a server is sending far more data than the size of
729 the complete resource representation.
731 8. Acknowledgments
733 See Section 12 of [Part1].
735 9. References
737 9.1. Normative References
739 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
740 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
741 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
742 and Message Parsing", draft-ietf-httpbis-p1-messaging-16
743 (work in progress), August 2011.
745 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
746 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
747 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
748 Requests", draft-ietf-httpbis-p4-conditional-16 (work in
749 progress), August 2011.
751 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
752 Extensions (MIME) Part Two: Media Types", RFC 2046,
753 November 1996.
755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
756 Requirement Levels", BCP 14, RFC 2119, March 1997.
758 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
759 Specifications: ABNF", STD 68, RFC 5234, January 2008.
761 9.2. Informative References
763 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
764 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
765 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
767 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
768 Procedures for Message Header Fields", BCP 90, RFC 3864,
769 September 2004.
771 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
772 Registration Procedures", BCP 13, RFC 4288, December 2005.
774 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
775 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
776 May 2008.
778 Appendix A. Internet Media Type multipart/byteranges
780 When an HTTP 206 (Partial Content) response message includes the
781 content of multiple ranges (a response to a request for multiple non-
782 overlapping ranges), these are transmitted as a multipart message-
783 body ([RFC2046], Section 5.1). The media type for this purpose is
784 called "multipart/byteranges". The following is to be registered
785 with IANA [RFC4288].
787 Note: Despite the name "multipart/byteranges" is not limited to
788 the byte ranges only.
790 The multipart/byteranges media type includes one or more parts, each
791 with its own Content-Type and Content-Range fields. The required
792 boundary parameter specifies the boundary string used to separate
793 each body-part.
795 Type name: multipart
797 Subtype name: byteranges
799 Required parameters: boundary
801 Optional parameters: none
803 Encoding considerations: only "7bit", "8bit", or "binary" are
804 permitted
806 Security considerations: none
808 Interoperability considerations: none
810 Published specification: This specification (see Appendix A).
812 Applications that use this media type:
814 Additional information:
816 Magic number(s): none
818 File extension(s): none
820 Macintosh file type code(s): none
822 Person and email address to contact for further information: See
823 Authors Section.
825 Intended usage: COMMON
827 Restrictions on usage: none
829 Author/Change controller: IESG
831 For example:
833 HTTP/1.1 206 Partial Content
834 Date: Wed, 15 Nov 1995 06:25:24 GMT
835 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
836 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
838 --THIS_STRING_SEPARATES
839 Content-type: application/pdf
840 Content-range: bytes 500-999/8000
842 ...the first range...
843 --THIS_STRING_SEPARATES
844 Content-type: application/pdf
845 Content-range: bytes 7000-7999/8000
847 ...the second range
848 --THIS_STRING_SEPARATES--
850 Other example:
852 HTTP/1.1 206 Partial Content
853 Date: Tue, 14 Nov 1995 06:25:24 GMT
854 Last-Modified: Tue, 14 July 04:58:08 GMT
855 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
857 --THIS_STRING_SEPARATES
858 Content-type: video/example
859 Content-range: exampleunit 1.2-4.3/25
861 ...the first range...
862 --THIS_STRING_SEPARATES
863 Content-type: video/example
864 Content-range: exampleunit 11.2-14.3/25
866 ...the second range
867 --THIS_STRING_SEPARATES--
869 Notes:
871 1. Additional CRLFs MAY precede the first boundary string in the
872 body.
874 2. Although [RFC2046] permits the boundary string to be quoted, some
875 existing implementations handle a quoted boundary string
876 incorrectly.
878 3. A number of browsers and servers were coded to an early draft of
879 the byteranges specification to use a media type of multipart/
880 x-byteranges, which is almost, but not quite compatible with the
881 version documented in HTTP/1.1.
883 Appendix B. Compatibility with Previous Versions
885 B.1. Changes from RFC 2616
887 Clarify that it is not ok to use a weak validator in a 206 response.
888 (Section 3.1)
890 Change ABNF productions for header fields to only define the field
891 value. (Section 5)
893 Clarify that multipart/byteranges can consist of a single part.
894 (Appendix A)
896 Appendix C. Collected ABNF
898 Accept-Ranges = acceptable-ranges
900 Content-Range = byte-content-range-spec / other-content-range-spec
902 HTTP-date =
904 If-Range = entity-tag / HTTP-date
906 OWS =
908 Range = byte-ranges-specifier / other-ranges-specifier
910 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
911 range-unit ] ) ) / "none"
913 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
914 instance-length / "*" )
915 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
916 byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
917 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
918 suffix-byte-range-spec ] ) )
919 byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
920 byte-ranges-specifier = bytes-unit "=" byte-range-set
921 bytes-unit = "bytes"
923 entity-tag =
925 first-byte-pos = 1*DIGIT
927 instance-length = 1*DIGIT
929 last-byte-pos = 1*DIGIT
931 other-content-range-spec = other-range-unit SP other-range-resp-spec
932 other-range-resp-spec = *CHAR
933 other-range-set = 1*CHAR
934 other-range-unit = token
935 other-ranges-specifier = other-range-unit "=" other-range-set
937 range-unit = bytes-unit / other-range-unit
939 suffix-byte-range-spec = "-" suffix-length
940 suffix-length = 1*DIGIT
942 token =
943 ABNF diagnostics:
945 ; Accept-Ranges defined but not used
946 ; Content-Range defined but not used
947 ; If-Range defined but not used
948 ; Range defined but not used
950 Appendix D. Change Log (to be removed by RFC Editor before publication)
952 D.1. Since RFC 2616
954 Extracted relevant partitions from [RFC2616].
956 D.2. Since draft-ietf-httpbis-p5-range-00
958 Closed issues:
960 o : "Cache
961 validators in 206 responses"
962 ()
964 o : "Normative and
965 Informative references"
967 o : "Normative up-
968 to-date references"
970 D.3. Since draft-ietf-httpbis-p5-range-01
972 Closed issues:
974 o : "Updating to
975 RFC4288"
977 Ongoing work on ABNF conversion
978 ():
980 o Add explicit references to BNF syntax and rules imported from
981 other parts of the specification.
983 D.4. Since draft-ietf-httpbis-p5-range-02
985 Ongoing work on IANA Message Header Field Registration
986 ():
988 o Reference RFC 3984, and update header field registrations for
989 headers defined in this document.
991 D.5. Since draft-ietf-httpbis-p5-range-03
993 None.
995 D.6. Since draft-ietf-httpbis-p5-range-04
997 Closed issues:
999 o : "multipart/
1000 byteranges minimum number of parts"
1002 Ongoing work on ABNF conversion
1003 ():
1005 o Use "/" instead of "|" for alternatives.
1007 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1008 whitespace ("OWS") and required whitespace ("RWS").
1010 o Rewrite ABNFs to spell out whitespace rules, factor out header
1011 field value format definitions.
1013 D.7. Since draft-ietf-httpbis-p5-range-05
1015 Closed issues:
1017 o : "State base
1018 for *-byte-pos and suffix-length"
1020 Ongoing work on Custom Ranges
1021 ():
1023 o Remove bias in favor of byte ranges; allow custom ranges in ABNF.
1025 Final work on ABNF conversion
1026 ():
1028 o Add appendix containing collected and expanded ABNF, reorganize
1029 ABNF introduction.
1031 D.8. Since draft-ietf-httpbis-p5-range-06
1033 Closed issues:
1035 o : "base for
1036 numeric protocol elements"
1038 D.9. Since draft-ietf-httpbis-p5-range-07
1040 Closed issues:
1042 o Fixed discrepancy in the If-Range definition about allowed
1043 validators.
1045 o : "multipart/
1046 byteranges for custom range units"
1048 o : "range unit
1049 missing from other-ranges-specifier in Range header"
1051 o : "move IANA
1052 registrations for optional status codes"
1054 D.10. Since draft-ietf-httpbis-p5-range-08
1056 No significant changes.
1058 D.11. Since draft-ietf-httpbis-p5-range-09
1060 No significant changes.
1062 D.12. Since draft-ietf-httpbis-p5-range-10
1064 Closed issues:
1066 o : "Clarify
1067 'Requested Variant'"
1069 o : "Clarify
1070 entity / representation / variant terminology"
1072 o : "consider
1073 removing the 'changes from 2068' sections"
1075 Ongoing work on Custom Ranges
1076 ():
1078 o Add IANA registry.
1080 D.13. Since draft-ietf-httpbis-p5-range-11
1082 Closed issues:
1084 o : "Caches can't
1085 be required to serve ranges"
1087 D.14. Since draft-ietf-httpbis-p5-range-12
1089 Closed issues:
1091 o : "Header
1092 Classification"
1094 D.15. Since draft-ietf-httpbis-p5-range-13
1096 Closed issues:
1098 o : "untangle
1099 ABNFs for header fields"
1101 D.16. Since draft-ietf-httpbis-p5-range-14
1103 None.
1105 D.17. Since draft-ietf-httpbis-p5-range-15
1107 Closed issues:
1109 o : "Security
1110 consideration: range flooding"
1112 Index
1114 2
1115 206 Partial Content (status code) 7
1117 4
1118 416 Requested Range Not Satisfiable (status code) 7
1120 A
1121 Accept-Ranges header field 9
1123 C
1124 Content-Range header field 9
1126 G
1127 Grammar
1128 Accept-Ranges 9
1129 acceptable-ranges 9
1130 byte-content-range-spec 10
1131 byte-range-resp-spec 10
1132 byte-range-set 13
1133 byte-range-spec 13
1134 byte-ranges-specifier 13
1135 bytes-unit 6
1136 Content-Range 10
1137 first-byte-pos 13
1138 If-Range 12
1139 instance-length 10
1140 last-byte-pos 13
1141 other-range-unit 6
1142 Range 15
1143 range-unit 6
1144 ranges-specifier 13
1145 suffix-byte-range-spec 14
1146 suffix-length 14
1148 H
1149 Header Fields
1150 Accept-Ranges 9
1151 Content-Range 9
1152 If-Range 12
1153 Range 13
1155 I
1156 If-Range header field 12
1158 M
1159 Media Type
1160 multipart/byteranges 18
1161 multipart/x-byteranges 20
1162 multipart/byteranges Media Type 18
1163 multipart/x-byteranges Media Type 20
1165 R
1166 Range header field 13
1168 S
1169 Status Codes
1170 206 Partial Content 7
1171 416 Requested Range Not Satisfiable 7
1173 Authors' Addresses
1175 Roy T. Fielding (editor)
1176 Adobe Systems Incorporated
1177 345 Park Ave
1178 San Jose, CA 95110
1179 USA
1181 EMail: fielding@gbiv.com
1182 URI: http://roy.gbiv.com/
1184 Jim Gettys
1185 Alcatel-Lucent Bell Labs
1186 21 Oak Knoll Road
1187 Carlisle, MA 01741
1188 USA
1190 EMail: jg@freedesktop.org
1191 URI: http://gettys.wordpress.com/
1193 Jeffrey C. Mogul
1194 Hewlett-Packard Company
1195 HP Labs, Large Scale Systems Group
1196 1501 Page Mill Road, MS 1177
1197 Palo Alto, CA 94304
1198 USA
1200 EMail: JeffMogul@acm.org
1202 Henrik Frystyk Nielsen
1203 Microsoft Corporation
1204 1 Microsoft Way
1205 Redmond, WA 98052
1206 USA
1208 EMail: henrikn@microsoft.com
1209 Larry Masinter
1210 Adobe Systems Incorporated
1211 345 Park Ave
1212 San Jose, CA 95110
1213 USA
1215 EMail: LMM@acm.org
1216 URI: http://larry.masinter.net/
1218 Paul J. Leach
1219 Microsoft Corporation
1220 1 Microsoft Way
1221 Redmond, WA 98052
1223 EMail: paulle@microsoft.com
1225 Tim Berners-Lee
1226 World Wide Web Consortium
1227 MIT Computer Science and Artificial Intelligence Laboratory
1228 The Stata Center, Building 32
1229 32 Vassar Street
1230 Cambridge, MA 02139
1231 USA
1233 EMail: timbl@w3.org
1234 URI: http://www.w3.org/People/Berners-Lee/
1236 Yves Lafon (editor)
1237 World Wide Web Consortium
1238 W3C / ERCIM
1239 2004, rte des Lucioles
1240 Sophia-Antipolis, AM 06902
1241 France
1243 EMail: ylafon@w3.org
1244 URI: http://www.raubacapeu.net/people/yves/
1245 Julian F. Reschke (editor)
1246 greenbytes GmbH
1247 Hafenweg 16
1248 Muenster, NW 48155
1249 Germany
1251 Phone: +49 251 2807760
1252 Fax: +49 251 2807761
1253 EMail: julian.reschke@greenbytes.de
1254 URI: http://greenbytes.de/tech/webdav/