W3C home > Mailing lists > Public > uri@w3.org > May 1995

Byte ranges -- formal spec proposal

From: Ari Luotonen <luotonen@netscape.com>
Date: Wed, 17 May 1995 13:22:40 -0700 (PDT)
Message-Id: <199505172022.NAA06472@neon.netscape.com>
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

   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
     * 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
     * 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
     * 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
   The first 500 bytes:


   The second 500 bytes:


   Bytes from 501 until the end of file:


   The last 500 bytes of the file:


   Two separate ranges:


   The first 100 bytes, 1000 bytes starting from the byte number 500, and
   the remainder of the file starting from byte number 4000:


   The first 100 bytes, 1000 bytes starting from the byte number 500, and
   the last 200 bytes of the file:


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

        Range: bytes X-Y/Z

          is the number of the first byte returned (the first byte is
          byte number one).
          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
          is the total size of the file in bytes.
   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


   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:


   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


        Range: chapters 1-3/12

   Or just the first chapter:


        Range: chapters 1/12

   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 

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

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:30 UTC