idnits 2.17.1 draft-ietf-httpbis-p5-range-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 26. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2616]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '... implementations MAY ignore ranges spe...' RFC 2119 keyword, line 137: '... The request MUST have included a Ra...' RFC 2119 keyword, line 138: '...sired range, and MAY have included an ...' RFC 2119 keyword, line 141: '... The response MUST include the follo...' RFC 2119 keyword, line 147: '... MUST match the actual number of ...' (38 more instances...) -- The draft header indicates that this document obsoletes RFC2068, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2007) is 5970 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-00 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2068, 2616 J. Gettys 5 (if approved) One Laptop per Child 6 Intended status: Standards Track J. Mogul 7 Expires: June 22, 2008 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 December 20, 2007 18 HTTP/1.1, part 5: Range Requests and Partial Responses 19 draft-ietf-httpbis-p5-range-00 21 Status of this Memo 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with Section 6 of BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 22, 2008. 46 Copyright Notice 48 Copyright (C) The IETF Trust (2007). 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 5 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines 58 range-specific requests and the rules for constructing and combining 59 responses to those requests. 61 Editorial Note (To be removed by RFC Editor) 63 This version of the HTTP specification contains only minimal 64 editorial changes from [RFC2616] (abstract, introductory paragraph, 65 and authors' addresses). All other changes are due to partitioning 66 the original into seven mostly independent parts. The intent is for 67 readers of future drafts to able to use draft 00 as the basis for 68 comparison when the WG makes later changes to the specification text. 69 This draft will shortly be followed by draft 01 (containing the first 70 round of changes that have already been agreed to on the mailing 71 list). There is no point in reviewing this draft other than to 72 verify that the partitioning has been done correctly. Roy T. 73 Fielding, Yves Lafon, and Julian Reschke will be the editors after 74 draft 00 is submitted. 76 Discussion of this draft should take place on the HTTPBIS working 77 group mailing list (ietf-http-wg@w3.org). The current issues list is 78 at and related 79 documents (including fancy diffs) can be found at 80 . 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4 87 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 4 88 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 5 89 4. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 5 90 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 6 91 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 6 92 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 7 93 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 9 96 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 11 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 Appendix A. Internet Media Type multipart/byteranges . . . . . . 13 102 Appendix B. Changes from RFC 2068 . . . . . . . . . . . . . . . . 14 103 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 105 Intellectual Property and Copyright Statements . . . . . . . . . . 18 107 1. Introduction 109 This document will define aspects of HTTP related to range requests, 110 partial responses, and the multipart/byteranges media type. Right 111 now it only includes the extracted relevant sections of RFC 2616 112 [RFC2616] without edit. 114 2. Range Units 116 HTTP/1.1 allows a client to request that only part (a range of) the 117 response entity be included within the response. HTTP/1.1 uses range 118 units in the Range (Section 5.4) and Content-Range (Section 5.2) 119 header fields. An entity can be broken down into subranges according 120 to various structural units. 122 range-unit = bytes-unit | other-range-unit 123 bytes-unit = "bytes" 124 other-range-unit = token 126 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 127 implementations MAY ignore ranges specified using other units. 129 HTTP/1.1 has been designed to allow implementations of applications 130 that do not depend on knowledge of ranges. 132 3. Status Code Definitions 134 3.1. 206 Partial Content 136 The server has fulfilled the partial GET request for the resource. 137 The request MUST have included a Range header field (Section 5.4) 138 indicating the desired range, and MAY have included an If-Range 139 header field (Section 5.3) to make the request conditional. 141 The response MUST include the following header fields: 143 o Either a Content-Range header field (Section 5.2) indicating the 144 range included with this response, or a multipart/byteranges 145 Content-Type including Content-Range fields for each part. If a 146 Content-Length header field is present in the response, its value 147 MUST match the actual number of OCTETs transmitted in the message- 148 body. 150 o Date 151 o ETag and/or Content-Location, if the header would have been sent 152 in a 200 response to the same request 154 o Expires, Cache-Control, and/or Vary, if the field-value might 155 differ from that sent in any previous response for the same 156 variant 158 If the 206 response is the result of an If-Range request that used a 159 strong cache validator (see Section 4 of [Part4]), the response 160 SHOULD NOT include other entity-headers. If the response is the 161 result of an If-Range request that used a weak validator, the 162 response MUST NOT include other entity-headers; this prevents 163 inconsistencies between cached entity-bodies and updated headers. 164 Otherwise, the response MUST include all of the entity-headers that 165 would have been returned with a 200 (OK) response to the same 166 request. 168 A cache MUST NOT combine a 206 response with other previously cached 169 content if the ETag or Last-Modified headers do not match exactly, 170 see 4. 172 A cache that does not support the Range and Content-Range headers 173 MUST NOT cache 206 (Partial) responses. 175 3.2. 416 Requested Range Not Satisfiable 177 A server SHOULD return a response with this status code if a request 178 included a Range request-header field (Section 5.4), and none of the 179 range-specifier values in this field overlap the current extent of 180 the selected resource, and the request did not include an If-Range 181 request-header field. (For byte-ranges, this means that the first- 182 byte-pos of all of the byte-range-spec values were greater than the 183 current length of the selected resource.) 185 When this status code is returned for a byte-range request, the 186 response SHOULD include a Content-Range entity-header field 187 specifying the current length of the selected resource (see 188 Section 5.2). This response MUST NOT use the multipart/byteranges 189 content-type. 191 4. Combining Byte Ranges 193 A response might transfer only a subrange of the bytes of an entity- 194 body, either because the request included one or more Range 195 specifications, or because a connection was broken prematurely. 196 After several such transfers, a cache might have received several 197 ranges of the same entity-body. 199 If a cache has a stored non-empty set of subranges for an entity, and 200 an incoming response transfers another subrange, the cache MAY 201 combine the new subrange with the existing set if both the following 202 conditions are met: 204 o Both the incoming response and the cache entry have a cache 205 validator. 207 o The two cache validators match using the strong comparison 208 function (see Section 4 of [Part4]). 210 If either requirement is not met, the cache MUST use only the most 211 recent partial response (based on the Date values transmitted with 212 every response, and using the incoming response if these values are 213 equal or missing), and MUST discard the other partial information. 215 5. Header Field Definitions 217 This section defines the syntax and semantics of all standard 218 HTTP/1.1 header fields. For entity-header fields, both sender and 219 recipient refer to either the client or the server, depending on who 220 sends and who receives the entity. 222 5.1. Accept-Ranges 224 The Accept-Ranges response-header field allows the server to indicate 225 its acceptance of range requests for a resource: 227 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges 228 acceptable-ranges = 1#range-unit | "none" 230 Origin servers that accept byte-range requests MAY send 232 Accept-Ranges: bytes 234 but are not required to do so. Clients MAY generate byte-range 235 requests without having received this header for the resource 236 involved. Range units are defined in Section 2. 238 Servers that do not accept any kind of range request for a resource 239 MAY send 241 Accept-Ranges: none 243 to advise the client not to attempt a range request. 245 5.2. Content-Range 247 The Content-Range entity-header is sent with a partial entity-body to 248 specify where in the full entity-body the partial body should be 249 applied. Range units are defined in Section 2. 251 Content-Range = "Content-Range" ":" content-range-spec 253 content-range-spec = byte-content-range-spec 254 byte-content-range-spec = bytes-unit SP 255 byte-range-resp-spec "/" 256 ( instance-length | "*" ) 258 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) 259 | "*" 260 instance-length = 1*DIGIT 262 The header SHOULD indicate the total length of the full entity-body, 263 unless this length is unknown or difficult to determine. The 264 asterisk "*" character means that the instance-length is unknown at 265 the time when the response was generated. 267 Unlike byte-ranges-specifier values (see Section 5.4.1), a byte- 268 range-resp-spec MUST only specify one range, and MUST contain 269 absolute byte positions for both the first and last byte of the 270 range. 272 A byte-content-range-spec with a byte-range-resp-spec whose last- 273 byte-pos value is less than its first-byte-pos value, or whose 274 instance-length value is less than or equal to its last-byte-pos 275 value, is invalid. The recipient of an invalid byte-content-range- 276 spec MUST ignore it and any content transferred along with it. 278 A server sending a response with status code 416 (Requested range not 279 satisfiable) SHOULD include a Content-Range field with a byte-range- 280 resp-spec of "*". The instance-length specifies the current length 281 of the selected resource. A response with status code 206 (Partial 282 Content) MUST NOT include a Content-Range field with a byte-range- 283 resp-spec of "*". 285 Examples of byte-content-range-spec values, assuming that the entity 286 contains a total of 1234 bytes: 288 o The first 500 bytes: 290 bytes 0-499/1234 292 o The second 500 bytes: 294 bytes 500-999/1234 296 o All except for the first 500 bytes: 298 bytes 500-1233/1234 300 o The last 500 bytes: 302 bytes 734-1233/1234 304 When an HTTP message includes the content of a single range (for 305 example, a response to a request for a single range, or to a request 306 for a set of ranges that overlap without any holes), this content is 307 transmitted with a Content-Range header, and a Content-Length header 308 showing the number of bytes actually transferred. For example, 310 HTTP/1.1 206 Partial content 311 Date: Wed, 15 Nov 1995 06:25:24 GMT 312 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 313 Content-Range: bytes 21010-47021/47022 314 Content-Length: 26012 315 Content-Type: image/gif 317 When an HTTP message includes the content of multiple ranges (for 318 example, a response to a request for multiple non-overlapping 319 ranges), these are transmitted as a multipart message. The multipart 320 media type used for this purpose is "multipart/byteranges" as defined 321 in Appendix A. See Appendix B for a compatibility issue. 323 A response to a request for a single range MUST NOT be sent using the 324 multipart/byteranges media type. A response to a request for 325 multiple ranges, whose result is a single range, MAY be sent as a 326 multipart/byteranges media type with one part. A client that cannot 327 decode a multipart/byteranges message MUST NOT ask for multiple byte- 328 ranges in a single request. 330 When a client requests multiple byte-ranges in one request, the 331 server SHOULD return them in the order that they appeared in the 332 request. 334 If the server ignores a byte-range-spec because it is syntactically 335 invalid, the server SHOULD treat the request as if the invalid Range 336 header field did not exist. (Normally, this means return a 200 337 response containing the full entity). 339 If the server receives a request (other than one including an If- 340 Range request-header field) with an unsatisfiable Range request- 341 header field (that is, all of whose byte-range-spec values have a 342 first-byte-pos value greater than the current length of the selected 343 resource), it SHOULD return a response code of 416 (Requested range 344 not satisfiable) (Section 3.2). 346 Note: clients cannot depend on servers to send a 416 (Requested 347 range not satisfiable) response instead of a 200 (OK) response for 348 an unsatisfiable Range request-header, since not all servers 349 implement this request-header. 351 5.3. If-Range 353 If a client has a partial copy of an entity in its cache, and wishes 354 to have an up-to-date copy of the entire entity in its cache, it 355 could use the Range request-header with a conditional GET (using 356 either or both of If-Unmodified-Since and If-Match.) However, if the 357 condition fails because the entity has been modified, the client 358 would then have to make a second request to obtain the entire current 359 entity-body. 361 The If-Range header allows a client to "short-circuit" the second 362 request. Informally, its meaning is `if the entity is unchanged, 363 send me the part(s) that I am missing; otherwise, send me the entire 364 new entity'. 366 If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) 368 If the client has no entity tag for an entity, but does have a Last- 369 Modified date, it MAY use that date in an If-Range header. (The 370 server can distinguish between a valid HTTP-date and any form of 371 entity-tag by examining no more than two characters.) The If-Range 372 header SHOULD only be used together with a Range header, and MUST be 373 ignored if the request does not include a Range header, or if the 374 server does not support the sub-range operation. 376 If the entity tag given in the If-Range header matches the current 377 entity tag for the entity, then the server SHOULD provide the 378 specified sub-range of the entity using a 206 (Partial content) 379 response. If the entity tag does not match, then the server SHOULD 380 return the entire entity using a 200 (OK) response. 382 5.4. Range 384 5.4.1. Byte Ranges 386 Since all HTTP entities are represented in HTTP messages as sequences 387 of bytes, the concept of a byte range is meaningful for any HTTP 388 entity. (However, not all clients and servers need to support byte- 389 range operations.) 391 Byte range specifications in HTTP apply to the sequence of bytes in 392 the entity-body (not necessarily the same as the message-body). 394 A byte range operation MAY specify a single range of bytes, or a set 395 of ranges within a single entity. 397 ranges-specifier = byte-ranges-specifier 398 byte-ranges-specifier = bytes-unit "=" byte-range-set 399 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) 400 byte-range-spec = first-byte-pos "-" [last-byte-pos] 401 first-byte-pos = 1*DIGIT 402 last-byte-pos = 1*DIGIT 404 The first-byte-pos value in a byte-range-spec gives the byte-offset 405 of the first byte in a range. The last-byte-pos value gives the 406 byte-offset of the last byte in the range; that is, the byte 407 positions specified are inclusive. Byte offsets start at zero. 409 If the last-byte-pos value is present, it MUST be greater than or 410 equal to the first-byte-pos in that byte-range-spec, or the byte- 411 range-spec is syntactically invalid. The recipient of a byte-range- 412 set that includes one or more syntactically invalid byte-range-spec 413 values MUST ignore the header field that includes that byte-range- 414 set. 416 If the last-byte-pos value is absent, or if the value is greater than 417 or equal to the current length of the entity-body, last-byte-pos is 418 taken to be equal to one less than the current length of the entity- 419 body in bytes. 421 By its choice of last-byte-pos, a client can limit the number of 422 bytes retrieved without knowing the size of the entity. 424 suffix-byte-range-spec = "-" suffix-length 425 suffix-length = 1*DIGIT 427 A suffix-byte-range-spec is used to specify the suffix of the entity- 428 body, of a length given by the suffix-length value. (That is, this 429 form specifies the last N bytes of an entity-body.) If the entity is 430 shorter than the specified suffix-length, the entire entity-body is 431 used. 433 If a syntactically valid byte-range-set includes at least one byte- 434 range-spec whose first-byte-pos is less than the current length of 435 the entity-body, or at least one suffix-byte-range-spec with a non- 436 zero suffix-length, then the byte-range-set is satisfiable. 437 Otherwise, the byte-range-set is unsatisfiable. If the byte-range- 438 set is unsatisfiable, the server SHOULD return a response with a 439 status of 416 (Requested range not satisfiable). Otherwise, the 440 server SHOULD return a response with a status of 206 (Partial 441 Content) containing the satisfiable ranges of the entity-body. 443 Examples of byte-ranges-specifier values (assuming an entity-body of 444 length 10000): 446 o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 448 o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- 449 999 451 o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- 452 500 454 o Or bytes=9500- 456 o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 458 o Several legal but not canonical specifications of the second 500 459 bytes (byte offsets 500-999, inclusive): 460 bytes=500-600,601-999 461 bytes=500-700,601-999 463 5.4.2. Range Retrieval Requests 465 HTTP retrieval requests using conditional or unconditional GET 466 methods MAY request one or more sub-ranges of the entity, instead of 467 the entire entity, using the Range request header, which applies to 468 the entity returned as the result of the request: 470 Range = "Range" ":" ranges-specifier 472 A server MAY ignore the Range header. However, HTTP/1.1 origin 473 servers and intermediate caches ought to support byte ranges when 474 possible, since Range supports efficient recovery from partially 475 failed transfers, and supports efficient partial retrieval of large 476 entities. 478 If the server supports the Range header and the specified range or 479 ranges are appropriate for the entity: 481 o The presence of a Range header in an unconditional GET modifies 482 what is returned if the GET is otherwise successful. In other 483 words, the response carries a status code of 206 (Partial Content) 484 instead of 200 (OK). 486 o The presence of a Range header in a conditional GET (a request 487 using one or both of If-Modified-Since and If-None-Match, or one 488 or both of If-Unmodified-Since and If-Match) modifies what is 489 returned if the GET is otherwise successful and the condition is 490 true. It does not affect the 304 (Not Modified) response returned 491 if the conditional is false. 493 In some cases, it might be more appropriate to use the If-Range 494 header (see Section 5.3) in addition to the Range header. 496 If a proxy that supports ranges receives a Range request, forwards 497 the request to an inbound server, and receives an entire entity in 498 reply, it SHOULD only return the requested range to its client. It 499 SHOULD store the entire received response in its cache if that is 500 consistent with its cache allocation policies. 502 6. IANA Considerations 504 TBD. 506 7. Security Considerations 508 No additional security considerations have been identified beyond 509 those applicable to HTTP in general [Part1]. 511 8. Acknowledgments 513 Most of the specification of ranges is based on work originally done 514 by Ari Luotonen and John Franks, with additional input from Steve 515 Zilles. 517 Based on an XML translation of RFC 2616 by Julian Reschke. 519 9. References 521 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 522 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 523 part 1: URIs, Connections, and Message Parsing", 524 draft-ietf-httpbis-p1-messaging-00 (work in progress), 525 December 2007. 527 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 528 Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, 529 part 4: Conditional Requests", 530 draft-ietf-httpbis-p4-conditional-00 (work in progress), 531 December 2007. 533 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 534 Extensions (MIME) Part Two: Media Types", RFC 2046, 535 November 1996. 537 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 538 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 539 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 541 Appendix A. Internet Media Type multipart/byteranges 543 When an HTTP 206 (Partial Content) response message includes the 544 content of multiple ranges (a response to a request for multiple non- 545 overlapping ranges), these are transmitted as a multipart message- 546 body. The media type for this purpose is called "multipart/ 547 byteranges". 549 The multipart/byteranges media type includes two or more parts, each 550 with its own Content-Type and Content-Range fields. The required 551 boundary parameter specifies the boundary string used to separate 552 each body-part. 554 Media Type name: multipart 556 Media subtype name: byteranges 558 Required parameters: boundary 560 Optional parameters: none 562 Encoding considerations: only "7bit", "8bit", or "binary" are 563 permitted 565 Security considerations: none 566 For example: 568 HTTP/1.1 206 Partial Content 569 Date: Wed, 15 Nov 1995 06:25:24 GMT 570 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT 571 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 573 --THIS_STRING_SEPARATES 574 Content-type: application/pdf 575 Content-range: bytes 500-999/8000 577 ...the first range... 578 --THIS_STRING_SEPARATES 579 Content-type: application/pdf 580 Content-range: bytes 7000-7999/8000 582 ...the second range 583 --THIS_STRING_SEPARATES-- 585 Notes: 587 1. Additional CRLFs may precede the first boundary string in the 588 entity. 590 2. Although RFC 2046 [RFC2046] permits the boundary string to be 591 quoted, some existing implementations handle a quoted boundary 592 string incorrectly. 594 3. A number of browsers and servers were coded to an early draft of 595 the byteranges specification to use a media type of multipart/ 596 x-byteranges, which is almost, but not quite compatible with the 597 version documented in HTTP/1.1. 599 Appendix B. Changes from RFC 2068 601 There are situations where a server (especially a proxy) does not 602 know the full length of a response but is capable of serving a 603 byterange request. We therefore need a mechanism to allow byteranges 604 with a content-range not indicating the full length of the message. 605 (Section 5.2) 607 Range request responses would become very verbose if all meta-data 608 were always returned; by allowing the server to only send needed 609 headers in a 206 response, this problem can be avoided. 611 Fix problem with unsatisfiable range requests; there are two cases: 612 syntactic problems, and range doesn't exist in the document. The 416 613 status code was needed to resolve this ambiguity needed to indicate 614 an error for a byte range request that falls outside of the actual 615 contents of a document. (Section 3.2, 5.2) 617 Index 619 2 620 206 Partial Content (status code) 4 622 4 623 416 Requested Range Not Satisfiable (status code) 5 625 A 626 Accept-Ranges header 6 628 C 629 Content-Range header 7 631 G 632 Grammar 633 Accept-Ranges 6 634 acceptable-ranges 6 635 byte-content-range-spec 7 636 byte-range-resp-spec 7 637 byte-range-set 10 638 byte-range-spec 10 639 byte-ranges-specifier 10 640 bytes-unit 4 641 Content-Range 7 642 content-range-spec 7 643 first-byte-pos 10 644 If-Range 9 645 instance-length 7 646 last-byte-pos 10 647 other-range-unit 4 648 Range 11 649 range-unit 4 650 ranges-specifier 10 651 suffix-byte-range-spec 10 652 suffix-length 10 654 H 655 Headers 656 Accept-Ranges 6 657 Content-Range 7 658 If-Range 9 659 Range 9 661 I 662 If-Range header 9 664 M 665 Media Type 666 multipart/byteranges 13 667 multipart/x-byteranges 14 668 multipart/byteranges Media Type 13 669 multipart/x-byteranges Media Type 14 671 R 672 Range header 9 674 S 675 Status Codes 676 206 Partial Content 4 677 416 Requested Range Not Satisfiable 5 679 Authors' Addresses 681 Roy T. Fielding (editor) 682 Day Software 683 23 Corporate Plaza DR, Suite 280 684 Newport Beach, CA 92660 685 USA 687 Phone: +1-949-706-5300 688 Fax: +1-949-706-5305 689 Email: fielding@gbiv.com 690 URI: http://roy.gbiv.com/ 692 Jim Gettys 693 One Laptop per Child 694 21 Oak Knoll Road 695 Carlisle, MA 01741 696 USA 698 Email: jg@laptop.org 699 URI: http://www.laptop.org/ 700 Jeffrey C. Mogul 701 Hewlett-Packard Company 702 HP Labs, Large Scale Systems Group 703 1501 Page Mill Road, MS 1177 704 Palo Alto, CA 94304 705 USA 707 Email: JeffMogul@acm.org 709 Henrik Frystyk Nielsen 710 Microsoft Corporation 711 1 Microsoft Way 712 Redmond, WA 98052 713 USA 715 Email: henrikn@microsoft.com 717 Larry Masinter 718 Adobe Systems, Incorporated 719 345 Park Ave 720 San Jose, CA 95110 721 USA 723 Email: LMM@acm.org 724 URI: http://larry.masinter.net/ 726 Paul J. Leach 727 Microsoft Corporation 728 1 Microsoft Way 729 Redmond, WA 98052 731 Email: paulle@microsoft.com 733 Tim Berners-Lee 734 World Wide Web Consortium 735 MIT Computer Science and Artificial Intelligence Laboratory 736 The Stata Center, Building 32 737 32 Vassar Street 738 Cambridge, MA 02139 739 USA 741 Email: timbl@w3.org 742 URI: http://www.w3.org/People/Berners-Lee/ 744 Full Copyright Statement 746 Copyright (C) The IETF Trust (2007). 748 This document is subject to the rights, licenses and restrictions 749 contained in BCP 78, and except as set forth therein, the authors 750 retain all their rights. 752 This document and the information contained herein are provided on an 753 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 754 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 755 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 756 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 757 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 760 Intellectual Property 762 The IETF takes no position regarding the validity or scope of any 763 Intellectual Property Rights or other rights that might be claimed to 764 pertain to the implementation or use of the technology described in 765 this document or the extent to which any license under such rights 766 might or might not be available; nor does it represent that it has 767 made any independent effort to identify any such rights. Information 768 on the procedures with respect to rights in RFC documents can be 769 found in BCP 78 and BCP 79. 771 Copies of IPR disclosures made to the IETF Secretariat and any 772 assurances of licenses to be made available, or the result of an 773 attempt made to obtain a general license or permission for the use of 774 such proprietary rights by implementers or users of this 775 specification can be obtained from the IETF on-line IPR repository at 776 http://www.ietf.org/ipr. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at 782 ietf-ipr@ietf.org. 784 Acknowledgment 786 Funding for the RFC Editor function is provided by the IETF 787 Administrative Support Activity (IASA).