Byte ranges -- formal spec proposal

Ari Luotonen (
Wed, 17 May 1995 17:47:36 +0500

Please review and comment.



May 16, 1995

John Franks <>
Ari Luotonen <>


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
Netscape Communications Corp.
501 East Middlefield Road
Mountain View, CA 94043, USA		Netscape Server Development Team