Re: Byte ranges -- formal spec proposal

On Thu, 18 May 1995, Chuck Shotton wrote:
> At 12:12 PM 5/18/95, David - Morris wrote:
> >On Thu, 18 May 1995, John Franks wrote:
> >> 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".
> 
> Not at all. The server that doesn't understand byte ranges views the entire
> URL as a file name. A file name with a bunch of numbers after it that
> wasn't found in the local file system. This is a perfect response to
> support backward compatibility with servers that don't implement or
> understand byte range syntax. 

I thought we were trying to get away from the file-system mindset?  :)

Actually, the interesting thing is that, at least with NCSA-variety servers,

  http://host/file;byterange=blah

returns a 404 not found, but

  http://host/file?foo;byterange=blah

returns the *whole* http://host/file.  The server simply supplies 
"foo;byterange=blah" as a QUERY_STRING CGI envvar, which might be used by 
server-side includes for example.  The ? doesn't make a difference to a 
client or proxy, but it does to a server.  Feh.

However, if, as I proposed, the client takes everything after the ; and 
makes them HTTP request headers, the server never sees ";byterange=blah" in 
the GET line of the HTTP request.

> Remember, the URL path is something that is
> ONLY understood by the server. A URL path is supposed to be opaque to
> EVERYTHING else, user, client, viewer, etc. It is strictly up to a server
> to determine if it can service a given URL and respond accordingly.

This is true.

> >> 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.
> 
> I agree. The first byte in a file is byte number 1. If I want the second
> thru fourth bytes of a file, I want to specify the range 2-4, not 1-3. The
> latter is hardly intuitive.

But if people aren't constructing these ranges by hand, what difference
does it make whether the number maps to the mnemonic that "the 1st object
should be called object number 1"?

> I still maintain that "?" is the appropriate separator for byte range
> syntax. 

Uh, how then do I use CGI QUERY_STRING variables along with byterange?  
How does a proxy (or a server, for that matter!) know when the info after 
the "?" is some sort of subaddressing parameter like byterange, or is CGI 
info?  A proxy would have to know the difference to base any sort of 
smart caching on this, and any system which prevented smart proxy caching 
is useless.

> You are asking the server to search for a particular range of bytes
> in a file, which is consistent with searching for keywords in a file, or
> coordinates on a map. As I mentioned earlier, semicolon has a specific
> meaning in many file systems that will conflict with its use as a separator
> for byte range info. The use of ";" is a bad choice.

But isn't "?" a perfectly valid Mac filename character too?

Ugh, sometimes this whole system just makes you want to scream.

> > 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.
> 
> Making a new HTTP header means that it will never gain support. Allowing it
> to be part of the URL (where it belongs in my opinion) means that it can be
> retrofitted into existing servers with the addition of a CGI. And as for #,
> ? is a better choice than that or ";".

Ask the URI working group where they would rather see this functionality 
implemented, and they'll probably say HTTP.  Why won't new HTTP headers 
get support?  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Thursday, 18 May 1995 17:45:29 UTC