Re: Byte ranges -- formal spec proposal

On Thu, 18 May 1995, John Franks wrote:

[...]
> are required and it works fine with all current browsers.  Indeed,
> essentially this proposal has been implemented and is widely used in
> both the GN and the WN servers (in the case of GN for over two years).
> It works fine with all browsers.

In that case, I would like to see some background on how the capability
has been used and the motivation. I have a real hard time
understanding why a user would want to type byte ranges, either as
a browser URL modifier or in a anchor.  Keeping such data in sync
would seem like a horrendous problem. So more on usage experience.

> 
> Some other clarifications:
> 
> 2) If a server chooses not to support byteranges for one document or
> all documents and for whatever reasons, it is quite appropriate to
> send a "document not found" status.   The server should not parse the

I don't agree ... this was one clear weakness in my mind in the 
original proposal.  "document not found" is a quite different state
from "this document doesn't support byterange".  My initial take on
the proposal was that it would be useful for recovery of interrupted
transmissions as well as helpful in some capacity limited situations
or to just get the shape of an image, etc.  Knowing byterange doesn't
apply could result in different recovery than the document doesnt' 
exist, etc.

> request and send the entire file when a range was requested.  The 
> behavior of current servers which do not support byteranges would be
> quite appropriate if they received a byterange request.

I would accept that only as minimaly sufficient, not quite appropriate.

> Two issues have been raised that I would like to hear more discussion
> on:
> 
> Should byteranges be 0 based or 1 based.  My initial view was that

It really depends on who is providing the values. Only a subset of
programmers think of the first object in an ordered set as being
the 0th object. People think of '1' (one) as the first object. If
there is any expectation that people will enter the values, one
is the correct choice.

> The second issue is also about possible future extensions.  Dan Connoly 
> pointed out that an '&' for multiple parameters would have to be 
> escaped in an anchor in an HTML document.  This is indeed a problem, 
> on the other hand it would be nice to have the same syntax as HTML form 
> URLs. 

I commented on & already and believe it to be the better choice.
Related is the choice of ';'.  Seems to me that the '#' is already
designated as a fragment identifier and what is being proposed is
a new form of fragment specification. If this proposal remains
as a http: URL rather than a new http header (which I would favor
depending on answers to the who&why question) then # would seem
more logical.


Dave Morris

Received on Thursday, 18 May 1995 12:14:29 UTC