# Byte ranges -- formal spec proposal

Ari Luotonen (luotonen@netscape.com)
Wed, 17 May 1995 13:22:40 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Larry Masinter: "Re: Scheduling: Area Tracks"
- Previous message: James Gosling: "Re: Byte ranges -- formal spec proposal"
- Next in thread: James Gosling: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: James Gosling: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Ronald E. Daniel: "Re: Byte ranges -- formal spec proposal"
- Reply: Daniel W. Connolly: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Chuck Shotton: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Chuck Shotton: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: John A. Kunze: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Larry Masinter: "Re: Byte ranges -- formal spec proposal"
- Reply: lazear@dockside.mitre.org: "Re: Byte ranges -- formal spec proposal"

    From: Ari Luotonen <luotonen@netscape.com>

    Message-Id: <199505172022.NAA06472@neon.netscape.com>

    Subject: Byte ranges -- formal spec proposal

    To: www-talk@w3.org, http-wg@cuckoo.hpl.hp.com

    Date: Wed, 17 May 1995 13:22:40 -0700 (PDT)

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

- Next message: Larry Masinter: "Re: Scheduling: Area Tracks"
- Previous message: James Gosling: "Re: Byte ranges -- formal spec proposal"
- Next in thread: James Gosling: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: James Gosling: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Ronald E. Daniel: "Re: Byte ranges -- formal spec proposal"
- Reply: Daniel W. Connolly: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Chuck Shotton: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Chuck Shotton: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: John A. Kunze: "Re: Byte ranges -- formal spec proposal"
- Maybe reply: Larry Masinter: "Re: Byte ranges -- formal spec proposal"
- Reply: lazear@dockside.mitre.org: "Re: Byte ranges -- formal spec proposal"