idnits 2.17.1 draft-ietf-httpbis-p5-range-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 9, 2009) is 5519 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-06 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-06 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-06 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-06 -- 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) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 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 Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track One Laptop per Child 6 Expires: September 10, 2009 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 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 March 9, 2009 22 HTTP/1.1, part 5: Range Requests and Partial Responses 23 draft-ietf-httpbis-p5-range-06 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may contain material 29 from IETF Documents or IETF Contributions published or made publicly 30 available before November 10, 2008. The person(s) controlling the 31 copyright in some of this material may not have granted the IETF 32 Trust the right to allow modifications of such material outside the 33 IETF Standards Process. Without obtaining an adequate license from 34 the person(s) controlling the copyright in such materials, this 35 document may not be modified outside the IETF Standards Process, and 36 derivative works of it may not be created outside the IETF Standards 37 Process, except to format it for publication as an RFC or to 38 translate it into languages other than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on September 10, 2009. 57 Copyright Notice 59 Copyright (c) 2009 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents in effect on the date of 64 publication of this document (http://trustee.ietf.org/license-info). 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. 68 Abstract 70 The Hypertext Transfer Protocol (HTTP) is an application-level 71 protocol for distributed, collaborative, hypermedia information 72 systems. HTTP has been in use by the World Wide Web global 73 information initiative since 1990. This document is Part 5 of the 74 seven-part specification that defines the protocol referred to as 75 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines 76 range-specific requests and the rules for constructing and combining 77 responses to those requests. 79 Editorial Note (To be removed by RFC Editor) 81 Discussion of this draft should take place on the HTTPBIS working 82 group mailing list (ietf-http-wg@w3.org). The current issues list is 83 at and related 84 documents (including fancy diffs) can be found at 85 . 87 The changes in this draft are summarized in Appendix D.7. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 92 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 93 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 94 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 95 1.2.2. ABNF Rules defined in other Parts of the 96 Specification . . . . . . . . . . . . . . . . . . . . 5 97 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5 98 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 99 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6 100 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6 101 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 7 102 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 103 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7 104 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8 105 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10 106 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11 107 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11 108 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 110 6.1. Message Header Registration . . . . . . . . . . . . . . . 14 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 112 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 116 Appendix A. Internet Media Type multipart/byteranges . . . . . . 15 117 Appendix B. Compatibility with Previous Versions . . . . . . . . 17 118 B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17 119 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18 120 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 18 121 Appendix D. Change Log (to be removed by RFC Editor before 122 publication) . . . . . . . . . . . . . . . . . . . . 19 123 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19 124 D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 20 125 D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 20 126 D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 20 127 D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 20 128 D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 20 129 D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 21 130 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 133 1. Introduction 135 HTTP clients often encounter interrupted data transfers as a result 136 of cancelled requests or dropped connections. When a cache has 137 stored a partial representation, it is desirable to request the 138 remainder of that representation in a subsequent request rather than 139 transfer the entire representation. There are also a number of Web 140 applications that benefit from being able to request only a subset of 141 a larger representation, such as a single page of a very large 142 document or only part of an image to be rendered by a device with 143 limited local storage. 145 This document defines HTTP/1.1 range requests, partial responses, and 146 the multipart/byteranges media type. The protocol for range requests 147 is an OPTIONAL feature of HTTP, designed so resources or recipients 148 that do not implement this feature can respond as if it is a normal 149 GET request without impacting interoperability. Partial responses 150 are indicated by a distinct status code to not be mistaken for full 151 responses by intermediate caches that might not implement the 152 feature. 154 Although the HTTP range request mechanism is designed to allow for 155 extensible range types, this specification only defines requests for 156 byte ranges. 158 1.1. Requirements 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 An implementation is not compliant if it fails to satisfy one or more 165 of the MUST or REQUIRED level requirements for the protocols it 166 implements. An implementation that satisfies all the MUST or 167 REQUIRED level and all the SHOULD level requirements for its 168 protocols is said to be "unconditionally compliant"; one that 169 satisfies all the MUST level requirements but not all the SHOULD 170 level requirements for its protocols is said to be "conditionally 171 compliant." 173 1.2. Syntax Notation 175 This specification uses the ABNF syntax defined in Section 1.2 of 176 [Part1] (which extends the syntax defined in [RFC5234] with a list 177 rule). Appendix C shows the collected ABNF, with the list rule 178 expanded. 180 The following core rules are included by reference, as defined in 182 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 183 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 184 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 185 sequence of data), SP (space), VCHAR (any visible USASCII character), 186 and WSP (whitespace). 188 1.2.1. Core Rules 190 The core rules below are defined in Section 1.2.2 of [Part1]: 192 token = 193 OWS = 195 1.2.2. ABNF Rules defined in other Parts of the Specification 197 The ABNF rules below are defined in other parts: 199 HTTP-date = 201 entity-tag = 203 2. Range Units 205 HTTP/1.1 allows a client to request that only part (a range of) the 206 response entity be included within the response. HTTP/1.1 uses range 207 units in the Range (Section 5.4) and Content-Range (Section 5.2) 208 header fields. An entity can be broken down into subranges according 209 to various structural units. 211 range-unit = bytes-unit / other-range-unit 212 bytes-unit = "bytes" 213 other-range-unit = token 215 HTTP/1.1 has been designed to allow implementations of applications 216 that do not depend on knowledge of ranges. The only range unit 217 defined by HTTP/1.1 is "bytes". 219 If a range unit is not understood in a request, a server MUST ignore 220 the whole Range header (Section 5.4). If a range unit is not 221 understood in a response, an intermediary SHOULD pass the response to 222 the client; a client MUST fail. 224 3. Status Code Definitions 225 3.1. 206 Partial Content 227 The server has fulfilled the partial GET request for the resource. 228 The request MUST have included a Range header field (Section 5.4) 229 indicating the desired range, and MAY have included an If-Range 230 header field (Section 5.3) to make the request conditional. 232 The response MUST include the following header fields: 234 o Either a Content-Range header field (Section 5.2) indicating the 235 range included with this response, or a multipart/byteranges 236 Content-Type including Content-Range fields for each part. If a 237 Content-Length header field is present in the response, its value 238 MUST match the actual number of OCTETs transmitted in the message- 239 body. 241 o Date 243 o ETag and/or Content-Location, if the header would have been sent 244 in a 200 response to the same request 246 o Expires, Cache-Control, and/or Vary, if the field-value might 247 differ from that sent in any previous response for the same 248 variant 250 If the 206 response is the result of an If-Range request, the 251 response SHOULD NOT include other entity-headers. Otherwise, the 252 response MUST include all of the entity-headers that would have been 253 returned with a 200 (OK) response to the same request. 255 A cache MUST NOT combine a 206 response with other previously cached 256 content if the ETag or Last-Modified headers do not match exactly, 257 see Section 4. 259 A cache that does not support the Range and Content-Range headers 260 MUST NOT cache 206 (Partial Content) responses. Furthermore, if a 261 response uses a range unit that is not understood by the cache, then 262 it MUST NOT be cached either. 264 3.2. 416 Requested Range Not Satisfiable 266 A server SHOULD return a response with this status code if a request 267 included a Range request-header field (Section 5.4), and none of the 268 ranges-specifier values in this field overlap the current extent of 269 the selected resource, and the request did not include an If-Range 270 request-header field. (For byte-ranges, this means that the first- 271 byte-pos of all of the byte-range-spec values were greater than the 272 current length of the selected resource.) 273 When this status code is returned for a byte-range request, the 274 response SHOULD include a Content-Range entity-header field 275 specifying the current length of the selected resource (see 276 Section 5.2). This response MUST NOT use the multipart/byteranges 277 content-type. 279 4. Combining Ranges 281 A response might transfer only a subrange of an entity-body, either 282 the request included one or more Range specifications, or because a 283 connection was broken prematurely. After several such transfers, a 284 cache might have received several ranges of the same entity-body. 286 If a cache has a stored non-empty set of subranges for an entity, and 287 an incoming response transfers another subrange, the cache MAY 288 combine the new subrange with the existing set if both the following 289 conditions are met: 291 o Both the incoming response and the cache entry have a cache 292 validator. 294 o The two cache validators match using the strong comparison 295 function (see Section 4 of [Part4]). 297 If either requirement is not met, the cache MUST use only the most 298 recent partial response (based on the Date values transmitted with 299 every response, and using the incoming response if these values are 300 equal or missing), and MUST discard the other partial information. 302 5. Header Field Definitions 304 This section defines the syntax and semantics of HTTP/1.1 header 305 fields related to range requests and partial responses. 307 For entity-header fields, both sender and recipient refer to either 308 the client or the server, depending on who sends and who receives the 309 entity. 311 5.1. Accept-Ranges 313 The response-header "Accept-Ranges" field allows the server to 314 indicate its acceptance of range requests for a resource: 316 Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v 317 Accept-Ranges-v = acceptable-ranges 318 acceptable-ranges = 1#range-unit / "none" 320 Origin servers that accept byte-range requests MAY send 322 Accept-Ranges: bytes 324 but are not required to do so. Clients MAY generate range requests 325 without having received this header for the resource involved. Range 326 units are defined in Section 2. 328 Servers that do not accept any kind of range request for a resource 329 MAY send 331 Accept-Ranges: none 333 to advise the client not to attempt a range request. 335 5.2. Content-Range 337 The entity-header "Content-Range" is sent with a partial entity-body 338 to specify where in the full entity-body the partial body should be 339 applied. Range units are defined in Section 2. 341 Content-Range = "Content-Range" ":" OWS Content-Range-v 342 Content-Range-v = content-range-spec 344 content-range-spec = byte-content-range-spec 345 / other-content-range-spec 346 byte-content-range-spec = bytes-unit SP 347 byte-range-resp-spec "/" 348 ( instance-length / "*" ) 350 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 351 / "*" 353 instance-length = 1*DIGIT 355 other-content-range-spec = other-range-unit SP 356 other-range-resp-spec 357 other-range-resp-spec = *CHAR 359 The header SHOULD indicate the total length of the full entity-body, 360 unless this length is unknown or difficult to determine. The 361 asterisk "*" character means that the instance-length is unknown at 362 the time when the response was generated. 364 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 365 range-resp-spec MUST only specify one range, and MUST contain 366 absolute byte positions for both the first and last byte of the 367 range. 369 A byte-content-range-spec with a byte-range-resp-spec whose last- 370 byte-pos value is less than its first-byte-pos value, or whose 371 instance-length value is less than or equal to its last-byte-pos 372 value, is invalid. The recipient of an invalid byte-content-range- 373 spec MUST ignore it and any content transferred along with it. 375 In the case of a byte range request: A server sending a response with 376 status code 416 (Requested range not satisfiable) SHOULD include a 377 Content-Range field with a byte-range-resp-spec of "*". The 378 instance-length specifies the current length of the selected resource 379 as a decimal number. A response with status code 206 (Partial 380 Content) MUST NOT include a Content-Range field with a byte-range- 381 resp-spec of "*". 383 Examples of byte-content-range-spec values, assuming that the entity 384 contains a total of 1234 bytes: 386 o The first 500 bytes: 388 bytes 0-499/1234 390 o The second 500 bytes: 392 bytes 500-999/1234 394 o All except for the first 500 bytes: 396 bytes 500-1233/1234 398 o The last 500 bytes: 400 bytes 734-1233/1234 402 When an HTTP message includes the content of a single range (for 403 example, a response to a request for a single range, or to a request 404 for a set of ranges that overlap without any holes), this content is 405 transmitted with a Content-Range header, and a Content-Length header 406 showing the number of bytes actually transferred. For example, 408 HTTP/1.1 206 Partial Content 409 Date: Wed, 15 Nov 1995 06:25:24 GMT 410 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 411 Content-Range: bytes 21010-47021/47022 412 Content-Length: 26012 413 Content-Type: image/gif 415 When an HTTP message includes the content of multiple ranges (for 416 example, a response to a request for multiple non-overlapping 417 ranges), these are transmitted as a multipart message. The multipart 418 media type used for this purpose is "multipart/byteranges" as defined 419 in Appendix A. See Appendix B.1 for a compatibility issue. 421 A response to a request for a single range MUST NOT be sent using the 422 multipart/byteranges media type. A response to a request for 423 multiple ranges, whose result is a single range, MAY be sent as a 424 multipart/byteranges media type with one part. A client that cannot 425 decode a multipart/byteranges message MUST NOT ask for multiple 426 ranges in a single request. 428 When a client requests multiple byte-ranges in one request, the 429 server SHOULD return them in the order that they appeared in the 430 request. 432 If the server ignores a byte-range-spec because it is syntactically 433 invalid, the server SHOULD treat the request as if the invalid Range 434 header field did not exist. (Normally, this means return a 200 435 response containing the full entity). 437 If the server receives a request (other than one including an If- 438 Range request-header field) with an unsatisfiable Range request- 439 header field (that is, all of whose byte-range-spec values have a 440 first-byte-pos value greater than the current length of the selected 441 resource), it SHOULD return a response code of 416 (Requested range 442 not satisfiable) (Section 3.2). 444 Note: clients cannot depend on servers to send a 416 (Requested 445 range not satisfiable) response instead of a 200 (OK) response for 446 an unsatisfiable Range request-header, since not all servers 447 implement this request-header. 449 5.3. If-Range 451 If a client has a partial copy of an entity in its cache, and wishes 452 to have an up-to-date copy of the entire entity in its cache, it 453 could use the Range request-header with a conditional GET (using 454 either or both of If-Unmodified-Since and If-Match.) However, if the 455 condition fails because the entity has been modified, the client 456 would then have to make a second request to obtain the entire current 457 entity-body. 459 The request header "If-Range" allows a client to "short-circuit" the 460 second request. Informally, its meaning is `if the entity is 461 unchanged, send me the part(s) that I am missing; otherwise, send me 462 the entire new entity'. 464 If-Range = "If-Range" ":" OWS If-Range-v 465 If-Range-v = entity-tag / HTTP-date 467 If the client has no entity tag for an entity, but does have a Last- 468 Modified date, it MAY use that date in an If-Range header. (The 469 server can distinguish between a valid HTTP-date and any form of 470 entity-tag by examining no more than two characters.) The If-Range 471 header SHOULD only be used together with a Range header, and MUST be 472 ignored if the request does not include a Range header, or if the 473 server does not support the sub-range operation. 475 If the entity tag given in the If-Range header matches the current 476 entity tag for the entity, then the server SHOULD provide the 477 specified sub-range of the entity using a 206 (Partial Content) 478 response. If the entity tag does not match, then the server SHOULD 479 return the entire entity using a 200 (OK) response. 481 5.4. Range 483 5.4.1. Byte Ranges 485 Since all HTTP entities are represented in HTTP messages as sequences 486 of bytes, the concept of a byte range is meaningful for any HTTP 487 entity. (However, not all clients and servers need to support byte- 488 range operations.) 490 Byte range specifications in HTTP apply to the sequence of bytes in 491 the entity-body (not necessarily the same as the message-body). 493 A byte range operation MAY specify a single range of bytes, or a set 494 of ranges within a single entity. 496 byte-ranges-specifier = bytes-unit "=" byte-range-set 497 byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec ) 498 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 499 first-byte-pos = 1*DIGIT 500 last-byte-pos = 1*DIGIT 502 The first-byte-pos value in a byte-range-spec gives the byte-offset 503 of the first byte in a range. The last-byte-pos value gives the 504 byte-offset of the last byte in the range; that is, the byte 505 positions specified are inclusive. Byte offsets are decimal and 506 start at zero. 508 If the last-byte-pos value is present, it MUST be greater than or 509 equal to the first-byte-pos in that byte-range-spec, or the byte- 510 range-spec is syntactically invalid. The recipient of a byte-range- 511 set that includes one or more syntactically invalid byte-range-spec 512 values MUST ignore the header field that includes that byte-range- 513 set. 515 If the last-byte-pos value is absent, or if the value is greater than 516 or equal to the current length of the entity-body, last-byte-pos is 517 taken to be equal to one less than the current length of the entity- 518 body in bytes. 520 By its choice of last-byte-pos, a client can limit the number of 521 bytes retrieved without knowing the size of the entity. 523 suffix-byte-range-spec = "-" suffix-length 524 suffix-length = 1*DIGIT 526 A suffix-byte-range-spec is used to specify the suffix of the entity- 527 body, of a length given by the decimal suffix-length value. (That 528 is, this form specifies the last N bytes of an entity-body.) If the 529 entity is shorter than the specified suffix-length, the entire 530 entity-body is used. 532 If a syntactically valid byte-range-set includes at least one byte- 533 range-spec whose first-byte-pos is less than the current length of 534 the entity-body, or at least one suffix-byte-range-spec with a non- 535 zero suffix-length, then the byte-range-set is satisfiable. 536 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 537 set is unsatisfiable, the server SHOULD return a response with a 538 status of 416 (Requested range not satisfiable). Otherwise, the 539 server SHOULD return a response with a status of 206 (Partial 540 Content) containing the satisfiable ranges of the entity-body. 542 Examples of byte-ranges-specifier values (assuming an entity-body of 543 length 10000): 545 o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 547 o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- 548 999 550 o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- 551 500 553 o Or bytes=9500- 555 o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 557 o Several legal but not canonical specifications of the second 500 558 bytes (byte offsets 500-999, inclusive): 559 bytes=500-600,601-999 560 bytes=500-700,601-999 562 5.4.2. Range Retrieval Requests 564 HTTP retrieval requests using conditional or unconditional GET 565 methods MAY request one or more sub-ranges of the entity, instead of 566 the entire entity, using the Range request header, which applies to 567 the entity returned as the result of the request: 569 Range = "Range" ":" OWS Range-v 570 Range-v = byte-ranges-specifier 571 / other-ranges-specifier 572 other-ranges-specifier = 1*CHAR 574 A server MAY ignore the Range header. However, HTTP/1.1 origin 575 servers and intermediate caches ought to support byte ranges when 576 possible, since Range supports efficient recovery from partially 577 failed transfers, and supports efficient partial retrieval of large 578 entities. 580 If the server supports the Range header and the specified range or 581 ranges are appropriate for the entity: 583 o The presence of a Range header in an unconditional GET modifies 584 what is returned if the GET is otherwise successful. In other 585 words, the response carries a status code of 206 (Partial Content) 586 instead of 200 (OK). 588 o The presence of a Range header in a conditional GET (a request 589 using one or both of If-Modified-Since and If-None-Match, or one 590 or both of If-Unmodified-Since and If-Match) modifies what is 591 returned if the GET is otherwise successful and the condition is 592 true. It does not affect the 304 (Not Modified) response returned 593 if the conditional is false. 595 In some cases, it might be more appropriate to use the If-Range 596 header (see Section 5.3) in addition to the Range header. 598 If a proxy that supports ranges receives a Range request, forwards 599 the request to an inbound server, and receives an entire entity in 600 reply, it SHOULD only return the requested range to its client. It 601 SHOULD store the entire received response in its cache if that is 602 consistent with its cache allocation policies. 604 6. IANA Considerations 605 6.1. Message Header Registration 607 The Message Header Registry located at should be 609 updated with the permanent registrations below (see [RFC3864]): 611 +-------------------+----------+----------+-------------+ 612 | Header Field Name | Protocol | Status | Reference | 613 +-------------------+----------+----------+-------------+ 614 | Accept-Ranges | http | standard | Section 5.1 | 615 | Content-Range | http | standard | Section 5.2 | 616 | If-Range | http | standard | Section 5.3 | 617 | Range | http | standard | Section 5.4 | 618 +-------------------+----------+----------+-------------+ 620 The change controller is: "IETF (iesg@ietf.org) - Internet 621 Engineering Task Force". 623 7. Security Considerations 625 No additional security considerations have been identified beyond 626 those applicable to HTTP in general [Part1]. 628 8. Acknowledgments 630 Most of the specification of ranges is based on work originally done 631 by Ari Luotonen and John Franks, with additional input from Steve 632 Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin 633 Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, 634 Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi 635 Rizzo, and Bill Weihl. 637 9. References 639 9.1. Normative References 641 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 642 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 643 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 644 and Message Parsing", draft-ietf-httpbis-p1-messaging-06 645 (work in progress), March 2009. 647 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 648 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 649 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 650 and Content Negotiation", draft-ietf-httpbis-p3-payload-06 651 (work in progress), March 2009. 653 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 654 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 655 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 656 Requests", draft-ietf-httpbis-p4-conditional-06 (work in 657 progress), March 2009. 659 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 660 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 661 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 662 draft-ietf-httpbis-p6-cache-06 (work in progress), 663 March 2009. 665 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 666 Extensions (MIME) Part Two: Media Types", RFC 2046, 667 November 1996. 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, March 1997. 672 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 673 Specifications: ABNF", STD 68, RFC 5234, January 2008. 675 9.2. Informative References 677 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 678 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 679 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 681 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 682 Procedures for Message Header Fields", BCP 90, RFC 3864, 683 September 2004. 685 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 686 Registration Procedures", BCP 13, RFC 4288, December 2005. 688 Appendix A. Internet Media Type multipart/byteranges 690 When an HTTP 206 (Partial Content) response message includes the 691 content of multiple ranges (a response to a request for multiple non- 692 overlapping ranges), these are transmitted as a multipart message- 693 body ([RFC2046], Section 5.1). The media type for this purpose is 694 called "multipart/byteranges". The following is to be registered 695 with IANA [RFC4288]. 697 The multipart/byteranges media type includes one or more parts, each 698 with its own Content-Type and Content-Range fields. The required 699 boundary parameter specifies the boundary string used to separate 700 each body-part. 702 Type name: multipart 704 Subtype name: byteranges 706 Required parameters: boundary 708 Optional parameters: none 710 Encoding considerations: only "7bit", "8bit", or "binary" are 711 permitted 713 Security considerations: none 715 Interoperability considerations: none 717 Published specification: This specification (see Appendix A). 719 Applications that use this media type: 721 Additional information: 723 Magic number(s): none 725 File extension(s): none 727 Macintosh file type code(s): none 729 Person and email address to contact for further information: See 730 Authors Section. 732 Intended usage: COMMON 734 Restrictions on usage: none 736 Author/Change controller: IESG 737 For example: 739 HTTP/1.1 206 Partial Content 740 Date: Wed, 15 Nov 1995 06:25:24 GMT 741 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 742 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 744 --THIS_STRING_SEPARATES 745 Content-type: application/pdf 746 Content-range: bytes 500-999/8000 748 ...the first range... 749 --THIS_STRING_SEPARATES 750 Content-type: application/pdf 751 Content-range: bytes 7000-7999/8000 753 ...the second range 754 --THIS_STRING_SEPARATES-- 756 Notes: 758 1. Additional CRLFs may precede the first boundary string in the 759 entity. 761 2. Although [RFC2046] permits the boundary string to be quoted, some 762 existing implementations handle a quoted boundary string 763 incorrectly. 765 3. A number of browsers and servers were coded to an early draft of 766 the byteranges specification to use a media type of multipart/ 767 x-byteranges, which is almost, but not quite compatible with the 768 version documented in HTTP/1.1. 770 Appendix B. Compatibility with Previous Versions 772 B.1. Changes from RFC 2068 774 Transfer-coding and message lengths all interact in ways that 775 required fixing exactly when chunked encoding is used (to allow for 776 transfer encoding that may not be self delimiting); it was important 777 to straighten out exactly how message lengths are computed. 778 (Section 5.2, see also [Part1], [Part3] and [Part6]) 780 There are situations where a server (especially a proxy) does not 781 know the full length of a response but is capable of serving a 782 byterange request. We therefore need a mechanism to allow byteranges 783 with a content-range not indicating the full length of the message. 785 (Section 5.2) 787 Range request responses would become very verbose if all meta-data 788 were always returned; by allowing the server to only send needed 789 headers in a 206 response, this problem can be avoided. (Section 3.1 790 and 5.3) 792 Fix problem with unsatisfiable range requests; there are two cases: 793 syntactic problems, and range doesn't exist in the document. The 416 794 status code was needed to resolve this ambiguity needed to indicate 795 an error for a byte range request that falls outside of the actual 796 contents of a document. (Section 3.2, 5.2) 798 B.2. Changes from RFC 2616 800 Clarify that it is not ok to use a weak cache validator in a 206 801 response. (Section 3.1) 803 Clarify that multipart/byteranges can consist of a single part. 804 (Appendix A) 806 Appendix C. Collected ABNF 808 Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v 809 Accept-Ranges-v = acceptable-ranges 811 Content-Range = "Content-Range:" OWS Content-Range-v 812 Content-Range-v = content-range-spec 814 HTTP-date = 816 If-Range = "If-Range:" OWS If-Range-v 817 If-Range-v = entity-tag / HTTP-date 819 OWS = 821 Range = "Range:" OWS Range-v 822 Range-v = byte-ranges-specifier / other-ranges-specifier 824 acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS 825 range-unit ] ) ) / "none" 827 byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( 828 instance-length / "*" ) 829 byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*" 830 byte-range-set = ( *( "," OWS ) byte-range-spec ) / ( 831 suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) / 832 suffix-byte-range-spec ] ) ) 833 byte-range-spec = first-byte-pos "-" [ last-byte-pos ] 834 byte-ranges-specifier = bytes-unit "=" byte-range-set 835 bytes-unit = "bytes" 837 content-range-spec = byte-content-range-spec / 838 other-content-range-spec 840 entity-tag = 842 first-byte-pos = 1*DIGIT 844 instance-length = 1*DIGIT 846 last-byte-pos = 1*DIGIT 848 other-content-range-spec = other-range-unit SP other-range-resp-spec 849 other-range-resp-spec = *CHAR 850 other-range-unit = token 851 other-ranges-specifier = 1*CHAR 853 range-unit = bytes-unit / other-range-unit 855 suffix-byte-range-spec = "-" suffix-length 856 suffix-length = 1*DIGIT 858 token = 860 ABNF diagnostics: 862 ; Accept-Ranges defined but not used 863 ; Content-Range defined but not used 864 ; If-Range defined but not used 865 ; Range defined but not used 867 Appendix D. Change Log (to be removed by RFC Editor before publication) 869 D.1. Since RFC2616 871 Extracted relevant partitions from [RFC2616]. 873 D.2. Since draft-ietf-httpbis-p5-range-00 875 Closed issues: 877 o : "Cache 878 validators in 206 responses" 879 () 881 o : "Normative and 882 Informative references" 884 o : "Normative up- 885 to-date references" 887 D.3. Since draft-ietf-httpbis-p5-range-01 889 Closed issues: 891 o : "Updating to 892 RFC4288" 894 Ongoing work on ABNF conversion 895 (): 897 o Add explicit references to BNF syntax and rules imported from 898 other parts of the specification. 900 D.4. Since draft-ietf-httpbis-p5-range-02 902 Ongoing work on IANA Message Header Registration 903 (): 905 o Reference RFC 3984, and update header registrations for headers 906 defined in this document. 908 D.5. Since draft-ietf-httpbis-p5-range-03 910 D.6. Since draft-ietf-httpbis-p5-range-04 912 Closed issues: 914 o : "multipart/ 915 byteranges minimum number of parts" 917 Ongoing work on ABNF conversion 918 (): 920 o Use "/" instead of "|" for alternatives. 922 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 923 whitespace ("OWS") and required whitespace ("RWS"). 925 o Rewrite ABNFs to spell out whitespace rules, factor out header 926 value format definitions. 928 D.7. Since draft-ietf-httpbis-p5-range-05 930 Closed issues: 932 o : "State base 933 for *-byte-pos and suffix-length" 935 Ongoing work on Custom Ranges 936 (): 938 o Remove bias in favor of byte ranges; allow custom ranges in ABNF. 940 Final work on ABNF conversion 941 (): 943 o Add appendix containing collected and expanded ABNF, reorganize 944 ABNF introduction. 946 Index 948 2 949 206 Partial Content (status code) 6 951 4 952 416 Requested Range Not Satisfiable (status code) 6 954 A 955 Accept-Ranges header 7 957 C 958 Content-Range header 8 960 G 961 Grammar 962 Accept-Ranges 7 963 Accept-Ranges-v 7 964 acceptable-ranges 7 965 byte-content-range-spec 8 966 byte-range-resp-spec 8 967 byte-range-set 11 968 byte-range-spec 11 969 byte-ranges-specifier 11 970 bytes-unit 5 971 Content-Range 8 972 content-range-spec 8 973 Content-Range-v 8 974 first-byte-pos 11 975 If-Range 10 976 If-Range-v 10 977 instance-length 8 978 last-byte-pos 11 979 other-range-unit 5 980 Range 13 981 range-unit 5 982 ranges-specifier 11 983 suffix-byte-range-spec 12 984 suffix-length 12 986 H 987 Headers 988 Accept-Ranges 7 989 Content-Range 8 990 If-Range 10 991 Range 11 993 I 994 If-Range header 10 996 M 997 Media Type 998 multipart/byteranges 15 999 multipart/x-byteranges 17 1000 multipart/byteranges Media Type 15 1001 multipart/x-byteranges Media Type 17 1003 R 1004 Range header 11 1006 S 1007 Status Codes 1008 206 Partial Content 6 1009 416 Requested Range Not Satisfiable 6 1011 Authors' Addresses 1013 Roy T. Fielding (editor) 1014 Day Software 1015 23 Corporate Plaza DR, Suite 280 1016 Newport Beach, CA 92660 1017 USA 1019 Phone: +1-949-706-5300 1020 Fax: +1-949-706-5305 1021 Email: fielding@gbiv.com 1022 URI: http://roy.gbiv.com/ 1024 Jim Gettys 1025 One Laptop per Child 1026 21 Oak Knoll Road 1027 Carlisle, MA 01741 1028 USA 1030 Email: jg@laptop.org 1031 URI: http://www.laptop.org/ 1033 Jeffrey C. Mogul 1034 Hewlett-Packard Company 1035 HP Labs, Large Scale Systems Group 1036 1501 Page Mill Road, MS 1177 1037 Palo Alto, CA 94304 1038 USA 1040 Email: JeffMogul@acm.org 1042 Henrik Frystyk Nielsen 1043 Microsoft Corporation 1044 1 Microsoft Way 1045 Redmond, WA 98052 1046 USA 1048 Email: henrikn@microsoft.com 1049 Larry Masinter 1050 Adobe Systems, Incorporated 1051 345 Park Ave 1052 San Jose, CA 95110 1053 USA 1055 Email: LMM@acm.org 1056 URI: http://larry.masinter.net/ 1058 Paul J. Leach 1059 Microsoft Corporation 1060 1 Microsoft Way 1061 Redmond, WA 98052 1063 Email: paulle@microsoft.com 1065 Tim Berners-Lee 1066 World Wide Web Consortium 1067 MIT Computer Science and Artificial Intelligence Laboratory 1068 The Stata Center, Building 32 1069 32 Vassar Street 1070 Cambridge, MA 02139 1071 USA 1073 Email: timbl@w3.org 1074 URI: http://www.w3.org/People/Berners-Lee/ 1076 Yves Lafon (editor) 1077 World Wide Web Consortium 1078 W3C / ERCIM 1079 2004, rte des Lucioles 1080 Sophia-Antipolis, AM 06902 1081 France 1083 Email: ylafon@w3.org 1084 URI: http://www.raubacapeu.net/people/yves/ 1085 Julian F. Reschke (editor) 1086 greenbytes GmbH 1087 Hafenweg 16 1088 Muenster, NW 48155 1089 Germany 1091 Phone: +49 251 2807760 1092 Fax: +49 251 2807761 1093 Email: julian.reschke@greenbytes.de 1094 URI: http://greenbytes.de/tech/webdav/