Re: Byte ranges -- formal spec proposal

On Thu, 18 May 1995, Ari Luotonen wrote:

> > What do you mean by "intentionally break" with servers that don't support it?
> 
> UNIX servers return a 404 Not found error because they use the whole
> thing as the filename.  Other servers will return either that, or some
> other error message.  In other words, it will be made clear to the
> client that the server doesn't understand byte range requests.  So I
> don't want servers to possibly ignore the ;byterange=... part and
> still return the entire document.  I want them to either service the
> byterange request, or give an error.

All fine ... but IF the server understands byterange, and it knows
that byterange does not apply to the 'document', they it should
present an error which the client can interpret to mean IF I WANT
THE DOCUMENT, it is only available without byterange. As proposed,
a UA which understands byterange would have to try a second request
w/o byte range just to learn the document didn't exist.

We can argue that URLs are opaque to the client but the client 
recognizes the # fragment identifier and strips it off. We also have
relative URLs. Both I believe are counter examples in current practice
to the opacity issue.

Given the rate of churn to new versions of client software, I find
that the argument for keeping the bytes in the URL means restricting 
changes to the server side only not very compelling.

I also can conceive that an HTML client which is very resource
constrained might be really clever and use byte range as
a way to manage local storage when the whole document wouldn't
fit. Receive it once, parse it, build a table of fragments and
re-retrieve pieces later with something like IF NOT CHANGED SINCE
and byterange.

But my fantasies don't apply to the current proposal. I'm still
waiting for elaboration on the experience and motivation alluded
to in one of the early posts.

Dave Morris

Received on Friday, 19 May 1995 15:32:26 UTC