- From: Ari Luotonen <luotonen@netscape.com>
- Date: Wed, 17 May 1995 13:22:40 -0700 (PDT)
- To: www-talk@w3.org, http-wg@cuckoo.hpl.hp.com
- Cc: uri@bunyip.com
Please review and comment. _________________________________________________________________ BYTE RANGES WITH URLS AND HTTP May 16, 1995 John Franks <john@math.nwu.edu> Ari Luotonen <ari@netscape.com> _________________________________________________________________ Table of Contents * Overview * The byterange Parameter + Examples * The Range HTTP Response Header + Examples * Miscellaneous _________________________________________________________________ Overview There are number of Web applications that would benefit from being able to request the server to give a byte range of a document. It may be argued that this should be left as a server-specific feature in the opaque URL, as the "parameters" used in URLs that may be available or useful can vary from server to server. However, there are reasons why standardizing the byte range feature would be beneficial. One of the primary reasons is to be able to support byte ranges in proxy servers. Without a standard proxy servers will have to treat each different byte range of a given document as a separate document. Should the notion of a byte range be standard, not only would it prevent portions of documents to be multiply cached, but it would make it possible for the server to generate range responses directly from its cache. _________________________________________________________________ Description of the byterange URL Parameter * The byte range request is attached to the end of the URL, separated by a semi-colon. * The parameter name is byterange. * The range is two integers greater than zero, separated by a hyphen. * The first byte in file is byte number 1. * One of the numbers may be missing, but both of them cannot at the same time. * If the first number is missing, it means to return n bytes from the end of the file, where n is the second number. * If the second number is missing, it means the end of file. * If the second number is larger than the size of the file, it is taken to mean the size of the file. * The first integer must always be less than or equal to the second one. * The range includes both limits, that is, a range 500-1000 means the 501 bytes between 499 and 1001. * There may be multiple ranges, separated by a comma. The order of the ranges is the preferred order in which the ranges should be returned. * In place of a range there may be only a single positive integer. This means only a single byte. This is not meaningful for byte ranges, but if and when this scheme gets extended to allow other kinds of ranges (such as lines, chapters or pages), this will be useful. _________________________________________________________________ EXAMPLES OF THE BYTERANGE URL PARAMETER The first 500 bytes: http://host/dir/foo;byterange=1-500 The second 500 bytes: http://host/dir/foo;byterange=501-1000 Bytes from 501 until the end of file: http://host/dir/foo;byterange=501- The last 500 bytes of the file: http://host/dir/foo;byterange=-500 Two separate ranges: http://host/dir/foo;byterange=51-100,201-250 The first 100 bytes, 1000 bytes starting from the byte number 500, and the remainder of the file starting from byte number 4000: http://host/dir/foo;byterange=1-100,500-1499,4000- The first 100 bytes, 1000 bytes starting from the byte number 500, and the last 200 bytes of the file: http://host/dir/foo;byterange=1-100,500-1499,-200 _________________________________________________________________ Description of the HTTP Response Headers If the request includes multiple ranges, the response is sent back as a multipart MIME message. If there are overlapping ranges the behaviour for each range doesn't change. That is, a range will not be truncated, or left out, just because there is an overlap. The following HTTP response header is sent back to provide verification and information about the range and total size of the file: Range: bytes X-Y/Z where: X is the number of the first byte returned (the first byte is byte number one). Y is the number of the last byte returned (in case of the end of the file this is the same number as the size of the file in bytes). Z is the total size of the file in bytes. _________________________________________________________________ EXAMPLES OF THE RANGE: HEADER The first 500 bytes of a 1234 byte file: Range: bytes 1-500/1234 The second 500 bytes of the same file: Range: bytes 501-1000/1234 Bytes from 501 until the end of the same file: Range: bytes 501-1234/1234 The last 500 bytes of the same file: Range: bytes 735-1234/1234 _________________________________________________________________ Miscellaneous There are other kinds of ranges that can be addressed in a similar fashion; this document does not define them, but both the URL parameter and the Range: header are defined so that it is possible to extend them. This byte range specification applies to any content-type. There may be range schemes that are meaningful to only certain types of documents. As an example, there might be a linerange URL parameter, with the same kind of range specification, and the Range: header would then specify the numbers in lines. Example: http://host/dir/foo;linerange=21-30 The response from a 123 line file would be: Range: lines 21-30/123 This could be useful for such things as structured text files like address lists or digests of mail and news, but isn't meaningful to such document types as GIF or PDF. Other examples might be document format specific ranges, such as chapters: http://host/dir/foo;chapterrange=1-3 Range: chapters 1-3/12 Or just the first chapter: http://host/dir/foo;chapterrange=1 Range: chapters 1/12 MULTIPLE URL PARAMETERS If at some point there will be multiple simultaneous URL parameters, they should be separated by the ampersand character (just like multiple values are encoded in the FORM request). _________________________________________________________________ John Franks, Ari Luotonen Cheers, -- Ari Luotonen ari@netscape.com Netscape Communications Corp. http://home.netscape.com/people/ari/ 501 East Middlefield Road Mountain View, CA 94043, USA Netscape Server Development Team
Received on Wednesday, 17 May 1995 16:29:24 UTC