Re: Byte ranges -- formal spec proposal

John Franks ([email protected])
Thu, 18 May 1995 14:45:02 +0500

According to Gavin Nicol:
>
> I do not like the idea of byte ranges being part of a URL.
> In DynaWeb for example
>
> http://www.ebt.com/collection/readers?byterange=1-500
>
> is absolutely meaningless, because the actual file size is not
> related to the size of the documents retrieved. Worse even,
> there are cases (and DynaWeb is one) where a single URL
> can possibly reference documents that differ in an
> arbitrary manner.
>
> In other words, byte ranges are not generally applicable to
> all objects accessible via a URL, so we cannot make this
> a requirement.
>

First, let me say that as far as I am concerned we are discussing
byte ranges for HTTP URLs, not for every URL. I assumed this was
understood. I, at least, am not suggesting changes to ftp or gopher
URLs.

Secondly, a couple of people have expressed concern over "making this
a requirement." I am not sure what this even means. No server is
ever "required" to honor any request. Requests are routinely denied
and there are HTTP status codes to communicate information about the
denial. The fact that a URL

http://host/path/foo

is honored in no way implies that the *different* URL

http://host/path/foo;byterange=1-500

is required also to be honored. It is quite acceptable to return an
"access denied" status for the second URL. Parameters like byterange
while very useful in some applications are useless, meaningless, hard
to serve, or even impossible to serve in other cases. We can all come
up with our favorite example. When a byterange is requested in such
an instance the server should simply refuse the request with an
appropriate status code. If a server does not support byteranges
(e.g. most current servers) and receives a request for one it will
presumably send a "file does not exist" status code. This is fine.

John Franks