idnits 2.17.1 draft-ietf-http-range-retrieval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 562 has weird spacing: '...ielding fie...' == Line 565 has weird spacing: '...amilton mar...' == Line 569 has weird spacing: '...z-Ortiz alop...' == Line 574 has weird spacing: '... Morris dwm...' -- 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 (February 22, 1996) is 10284 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) == Unused Reference: 'HTTP' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'CGI' is defined on line 542, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Downref: Normative reference to an Informational draft: draft-ietf-http-v10-spec (ref. 'HTTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'CGI' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ari Luotonen 2 Expires: August, 1996 Netscape Communications Corporation 3 John Franks 4 Northwestern University 5 February 22, 1996 7 Byte Range Retrieval Extension to HTTP 9 STATUS OF THIS MEMO 11 This document supersedes . 13 A subgroup of the HTTP working group has developed this after several 14 rounds of discussion. Some but not all parts of this proposal are 15 currently implemented in commercial Web servers and browsers. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 TABLE OF CONTENTS 35 1. Overview ................................................. 2 37 2. Accept-Ranges HTTP response header ....................... 3 39 3. Byte range HTTP request .................................. 3 40 3.1. The Range HTTP request header ............................ 3 41 3.2. Conditional Range retrievals.............................. 5 43 4. Byte range HTTP response ................................. 7 44 4.1. 206 Partial Content status code .......................... 7 45 4.2. The Content-Range HTTP response header ................... 8 47 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 49 4.3. Multiple ranges as multipart MIME messages ............... 9 50 4.4. Caching issues .......................................... 10 52 5. Future considerations ................................... 10 53 5.1. Extending Accept-Ranges, Range and Content-Range headers 10 54 5.2. Other possible ranges ................................... 11 56 6. References .............................................. 12 58 7. Authors' Addresses ...................................... 12 59 Contributors ............................................ 12 61 1. OVERVIEW 63 It is possible in Web clients to interrupt the connection before the 64 data transfer has finished. As a result the client may have partial 65 documents or images loaded into its memory. It would be useful to be 66 able to request the server to return the missing portion of the 67 document only, instead of retransferring the entire file, if the page 68 is re-entered later. 70 There are also a number of Web applications that would benefit from 71 being able to request the server to give a byte range of a document. 72 As an example an Adobe PDF viewer would need to be able to access 73 individual pages by byte range; the table that defines those ranges 74 is located at the end of the PDF file (this is the case in the new 75 to-be-released PDF format). 77 Setting this standard will promote interoperability between clients, 78 servers and intermediate proxy servers, make (partial) caching 79 effective, and save bandwidth. 81 This specification defines only the byte ranges. It shows other 82 types of ranges as an example of how this specification could be 83 extended, as proof of its generality. Those examples should not be 84 viewed as their definition. 86 This specification is simple enough to be adopted quickly by the 87 server authors/vendors, and be quickly and easily exploited on the 88 client side. The proposed solution will be backward compatible with 89 existing proxy servers, and once this specification becomes official 90 it will actually be possible to support this in a smart way in proxy 91 servers. 93 This specification can be applied to document types for which byte 94 ranges make sense; there are types for which they don't, and this 95 specification is not trying to enforce semantics for byte ranges for 97 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 99 them. In practice most of the data in the Web is represented as a 100 byte stream, and can be addressed with a byte range to retrieve a 101 desired portion of it. This is especially useful when there is a 102 partial copy of the document, the transfer of which was interrupted 103 by the user, but later resumed, in which case only the missing 104 portion needs to be transferred. 106 Byte range requests are typically generated by software, not written 107 by humans. 109 2. ACCEPT-RANGES HTTP RESPONSE HEADER 111 The server needs to let the client know that it can support byte 112 ranges. This is done through the Accept-Ranges HTTP header when a 113 server is returning a document that supports byte ranges: 115 Accept-Ranges: bytes 117 The server will send this header only for documents for which it will 118 be able to satisfy the byte range request, e.g. for PDF documents, or 119 images, which can be partially reloaded if the user interrupts the 120 page load, and image gets only partially cached. 122 Because of the architecture of the byte range request and response, 123 the client is not limited to attempting to use byte ranges only when 124 this header is present. The Request-Range header is simply ignored 125 by a server that does not support it, and it will send the entire 126 document as a response. 128 3. BYTE RANGE HTTP REQUEST 130 Byte range request is made like any other HTTP request, with the 131 addition of the Range: HTTP Request header. 133 3.1. The Range HTTP Request Header 135 The client requests a byte range via the Range: HTTP header: 137 Range: bytes=0-500,5000- 139 The Range: header is defined extensibly so that it can take a generic 140 parameter specifying the type of range. The parameter name for byte 141 ranges is "bytes". The syntax of this parameter is described below. 143 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 145 The name of the byte range parameter is bytes. It is passed to the 146 server in the Range: HTTP request header, followed by an equal sign 147 and the byte range specification. (In an earlier version of this 148 draft, it was passed to the server appended to the end of the path 149 part of the URL, separated by a semicolon). 151 Note About CGI Applications 153 As defined by the CGI/1.1 specification, the value of the Range: 154 header will be passed to CGI scripts in the HTTP_RANGE environment 155 variable. The CGI applications can choose to support it if they 156 so desire, and if it is possible. If the CGI applications do not 157 support it, or if the content they return changes from call to 158 call, they simply ignore the presence of that header, and return 159 the entire document. 161 Each range consists of one or two non-negative integers, separated by 162 a hyphen. The first integer must always be less than or equal to the 163 second one. One of these integers may be missing, but not both at the 164 same time. The hyphen is always there, so it is possible to tell 165 which number is missing. 167 If the first number is missing, it means to return the n last bytes 168 of the document, where n is the second number. If n is equal to, or 169 larger than, the size of the document minus one, then the entire file 170 is returned. 172 If the second number is missing, it means the end of document. That 173 is, all the bytes starting from byte n until the end of the document, 174 where n is the first number. 176 The first byte in a document is byte number 0. 178 If the second number is larger than the size of the document minus 179 one, it is taken to mean the size of the document minus one (that is, 180 the end of the document). 182 The range is inclusive; as an example, the range 500-1000 includes 183 bytes from 500 to 1000, including 500 and 1000. 185 There may be multiple ranges, separated by a comma. The order of the 186 ranges is the preferred order in which the ranges should be returned. 188 In the case that the second integer is smaller than the first one, 189 that particular range is tagged as invalid, and ignored. If it was 190 the only requested byte range, the entire document is returned. 192 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 194 Otherwise the remaining valid ranges will be returned. 196 The byte ranges refer to ranges in data as they are transferred over 197 the network (and retrieved by the client). E.g. if in an imaginary 198 system the server stores all lines terminated by CR LF, but turns 199 them into a single LF before sending the data, then byte ranges refer 200 to ranges inside this modified data (the one with single LF line 201 separators). That is, the ranges refer to the data that the client 202 would see. 204 The byte ranges apply to the "raw" data, that is, the data encoded by 205 Content-encoding; but not to the "armored" data, that is, the data 206 encoded by content-transfer-encoding. 208 Examples of the Range: header with the bytes parameter 210 The first 500 bytes: 212 Range: bytes=0-499 214 The second 500 bytes: 216 Range: bytes=500-999 218 All bytes except for the first 500 until the end of document: 220 Range: bytes=500- 222 The last 500 bytes of the document: 224 Range: bytes=-500 226 Two separate ranges: 228 Range: bytes=50-99,200-249 230 The first 100 bytes, 1000 bytes starting from the byte number 500, 231 and the remainder of the document starting from byte number 4000 232 (byte numbering starts from zero): 234 Range: bytes=0-99,500-1499,4000- 236 The first 100 bytes, 1000 bytes starting from the byte number 500, 237 and the last 200 bytes of the document: 239 Range: bytes=0-99,500-1499,-200 241 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 243 3.2 Conditional Range Retrievals 245 There are three cases of Range retrievals: 247 A) Unconditional 248 B) Insertion 249 C) Tentative 251 A) Unconditional Range Retrieval 253 An unconditional range retrieval always returns the selected range 254 (if it exists). 256 Servers that do not support Range: return entire resource. 258 B) Insertion Range Retrieval 260 Insertion type range retrieval returns the selected range if the 261 request-validator is valid, otherwise returns entire resource. 263 Servers that do not support Range: return entire resource if the 264 validator is valid, else return nothing + "306 Modified". 266 Case (B) is for filling in a hole in a cached resource, perhaps after 267 an interrupted retrieval, or perhaps after a previous Unconditional 268 or Tentative Range: request. 270 Note that if the server does not support Range:, it requires an extra 271 round-trip to update a cached resource with a hole in it. 273 C) Tentative Range Retrieval 275 A tentative range retrieval returns the selected range if the 276 request-validator is NOT valid, otherwise returns nothing + "304 Not 277 Modified" 279 Servers that do not support Range: return entire resource if the 280 validator is not valid, else return nothing + "304 Not Modified". 282 Case (C) is a way of asking only for a specified range, but in a way 283 that reloads it only if the client's cache is stale. For example, 284 you may have a large GIF image in your cache, and you may want to 285 know if its GIF header has changed (so that you can do an early 286 rendering of the enclosing HTML file), but you do not want to 287 retrieve the whole image right away. 289 Examples 290 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 292 The three cases are implemented in HTTP/1.1 using some combination of 293 these three headers 294 Range: 295 If-invalid: 296 If-valid: 297 or 298 Range: 299 If-Modified-Since: 300 Unless-Modified-Since: 302 See (*) below for more about using *-Modified-Since. 304 Case A (Unconditional) is done using 306 GET /image.gif HTTP/1.0 307 Range: bytes=0-128 309 Case B (Insertion) is done using 311 GET /image.gif HTTP/1.0 312 Range: bytes=0-128 313 If-valid: "xxxyxxyx" 314 or 315 GET /image.gif HTTP/1.0 316 Range: bytes=0-128 317 Unless-modified-since: Wed, 15 Nov 1995 06:25:15 GMT 319 Case C (Tentative) is done using 321 GET /image.gif HTTP/1.0 322 Range: bytes=0-128 323 If-invalid: "xxxyxxyx" 324 or 325 GET /image.gif HTTP/1.0 326 Range: bytes=0-128 327 If-modified-since: Wed, 15 Nov 1995 06:25:15 GMT 329 (*) We can get rid of "Unless-modified-since:" if we adopt the rule 330 that the "If-valid:" header either takes a quoted string (in which 331 case it is an opaque validator) or a string that does not include 332 quotes (in which case it must be an HTTP-date value). This saves a 333 few header bytes. 335 4. BYTE RANGE HTTP RESPONSE 337 4.1. 206 Partial Content Status Code 338 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 340 The byte range response uses the 206 Partial Content HTTP response 341 status. Servers and CGI applications not supporting byte ranges will 342 simply ignore the Range: header in the request, and return the entire 343 document in a 200 response. 345 Existing proxy servers only cache 200 Ok responses. This way 346 intermediate proxy servers will not mistakenly cache a partial 347 document as if it was the entire document. 349 If the request includes multiple ranges, the response is sent back as 350 a multipart MIME message, with content-type multipart/x-byteranges. 351 A server may, but is not required to, send also a single byte range 352 as a multipart message. 354 If there are overlapping ranges the behavior for each range doesn't 355 change. That is, a range will not be truncated, merged, or left out, 356 just because there is an overlap. 358 If a request that includes a Range: header also includes an Unless- 359 Modified-Since header and the resource was modified since the 360 specified time, or also includes an If-Valid header and the validator 361 does not match, 363 if the server supports Range:, it will send a normal 200 OK 364 response, and transfer the entire resource instead. 366 if the server does not support Range:, it will send 306 Modified 367 response, and will not transfer any part of the resource. 369 if the server supports neither Range: nor the validation header 370 (Unless-Modified-Since or If-Valid) then it will send a normal 200 371 OK response, and transfer the entire resource. 373 If a request that includes a Range: header also includes an If- 374 Modified-Since header and the resource was not modified since the 375 specified time, or also includes an If-Invalid header and the 376 validator matches, the server will send a 304 Not Modified response, 377 and will not transfer any part of the resource. 379 4.2 The Content-Range HTTP Response Header 381 The Content-Range HTTP response header is sent back to provide 382 verification and information about the range and total size of the 383 document. This header can be used by the client to determine which 384 one of the requested ranges is in question. Syntax: 386 Content-Range: bytes X-Y/Z 388 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 390 where: 392 X is the number of the first byte returned (the first byte is 393 byte number zero). 395 Y is the number of the last byte returned (in case of the end of 396 the document this is one smaller than the size of the document 397 in bytes). 399 Z is the total size of the document in bytes. 401 Examples of the Content-Range: HTTP Response Header 403 The first 500 bytes of a 1234 byte document: 405 Content-Range: bytes 0-499/1234 407 The second 500 bytes of the same document: 409 Content-Range: bytes 500-999/1234 411 All bytes until the end of document, except for the first 500 bytes: 413 Content-Range: bytes 500-1233/1234 415 The last 500 bytes of the same document: 417 Content-Range: bytes 734-1233/1234 419 Example of a response: 421 HTTP/1.0 206 Partial content 422 Server: Netscape-Communications/2.0 423 Date: Wed, 15 Nov 1995 06:25:24 GMT 424 Last-modified: Wed, 15 Nov 1995 04:58:08 GMT 425 Content-range: 21010-47021/47022 426 Content-length: 26012 427 Content-type: image/gif 429 4.3. Multiple Ranges as Multipart MIME Messages 431 Multipart MIME is defined in [RFC-1521]. With byteranges, the 432 multipart MIME message uses content-type multipart/x-byteranges, with 433 a boundary parameter. 435 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 437 Example: 439 Content-type: multipart/x-byteranges; boundary=THIS_STRING_SEPARATES 441 --THIS_STRING_SEPARATES 442 Content-type: application/x-pdf 443 Content-range: bytes 500-999/8000 445 ...the first range... 446 --THIS_STRING_SEPARATES 447 Content-type: application/x-pdf 448 Content-range: bytes 7000-7999/8000 450 ...the second range... 451 --THIS_STRING_SEPARATES-- 453 4.4. Caching Issues 455 The server must give Last-modified headers for each range request 456 whenever possible, and the client side must take care of having all 457 the fragments in sync. Conditional GET (the GET request with the If- 458 modified-since header) works as expected with byte ranges. That is, 459 the requested range is returned if the document has been modified 460 since the given date. Otherwise, a 304 Not Modified response is 461 sent. 463 Ranges can be cached, and if the Last-modified header matches they 464 can be combined. If a received Last-modified date at any time 465 differs from the ones in the cache, all the cached ranges will be 466 discarded. 468 The client side should monitor the Last-modified header value 469 returned by the server, and make sure that all of its individual 470 fragments are in sync. If there are older ones they should be 471 immediately discarded and re-retrieved. 473 5. FUTURE CONSIDERATIONS 475 5.1. Extending Accept-Ranges, Range and Content-Range headers 477 If at some point there will be additional parameters for the Range: 478 header, they should be separated by the semicolon character. 480 Example: 482 Range: param1=bar; param2=xyzzy 484 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 486 This specification does not define semantics for cases with multiple 487 Range: parameters. Future specifications should define semantics for 488 these. Until then, Range: headers with parameters that cannot be 489 understood should be ignored. 491 5.2. Other Possible Ranges 493 There are other kinds of ranges that can be addressed in a similar 494 fashion; this document does not define them, but both the Range: HTTP 495 request header and the Content-Range: HTTP header are defined so that 496 it is possible to extend them. 498 As an example, there might be a "lines" parameter, with the same kind 499 of range specification, and the Content-Range: header would then 500 specify the numbers in lines. Example: 502 GET /dir/foo HTTP/1.0 503 Range: lines=20-30 505 The response from a 123 line document would be: 507 HTTP/1.0 206 Partial Content 508 Content-Range: lines 20-30/123 509 Last-Modified: ... 510 Content-Length: 773 511 Content-Type: text/plain 513 This could be useful for such things as structured text files like 514 address lists or digests of mail and news, but isn't meaningful to 515 such document types as GIF or PDF. 517 Other examples might be document format specific ranges, such as 518 chapters: 520 GET /dir/foo HTTP/1.0 521 Range: chapters=6-9 523 206 Partial Content 524 Content-Range: chapters 6-9/12 525 Last-Modified: ... 526 Content-Length: 36023 527 Content-Type: application/x-book-type 529 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996 531 6. References 533 [RFC-1521] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 534 Extensions), Part One: Mechanisms for Specifying and 535 Describing the Format of Internet Message Bodies", 536 RFC 1521, Bellcore, Innosoft, September 1993 538 [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext 539 Transfer Protocol -- HTTP/1.0", 540 draft-ietf-http-v10-spec-04.html, October 14, 1995. 542 [CGI] R. McCool et al, "Common Gateway Interface -- CGI/1.1", 543 http://hoohoo.ncsa.uiuc.edu/cgi/, NCSA, 1994. 545 7. Authors' Addresses: 547 Ari Luotonen 548 Netscape Communications Corporation 549 501 E. Middlefield Road 550 Mountain View, CA 94043 551 USA 553 John Franks 554 Department of Mathematics 555 Northwestern University 556 Evanston, IL 60208-2730 558 The subgroup of the HTTP working group that contributed in producing 559 this draft (in alphabetical order; apologies for any omissions): 561 Daniel W. Connolly connolly@beach.w3.org 562 Roy T. Fielding fielding@avron.ics.uci.edu 563 John Franks john@math.nwu.edu 564 Jim Gettys jg@w3.org 565 Martin Hamilton martin@mrrl.lut.ac.uk 566 Koen Holtman koen@win.tue.nl 567 Shel Kaplan sjk@amazon.com 568 Paul Leach paulle@microsoft.com 569 Alex Lopez-Ortiz alopez-o@barrow.uwaterloo.ca 570 Ari Luotonen luotonen@netscape.com 571 Larry Masinter masinter@parc.xerox.com 572 Jeff Mogul mogul@pa.dec.com 573 Lou Montulli montulli@mozilla.com 574 David W. Morris dwm@shell.portal.com 575 Luigi Rizzo luigi@labinfo.iet.unipi.it 576 Bill Weihl weihl@pa.dec.com 577 Steve Zilles szilles@mv.us.adobe.com 579 BYTE RANGE RETRIEVAL EXTENSION TO HTTP INTERNET-DRAFT February 1996