Re: Byte ranges -- formal spec proposal

  > Date:  Wed, 17 May 1995 17:50:00 +0800
  > From:  jag@scndprsn.eng.sun.com (James Gosling)
  > To:    connolly@beach.w3.org, john@math.nwu.edu
  > CC:    luotonen@netscape.com, www-talk@w3.org, http-wg@cuckoo.hpl.hp.com,
	   uri@bunyip.com

  > > According to Daniel W. Connolly:
  > > > 
  > > > A nice, clear, complete proposal. As you say, this could be done as a
  > > > server-private mechanism, but there's no reason why everybody
  > > > shouldn't do it the same way.
  > > > 
  > > > A couple nits:
  > > > 
  > > > >     * The first byte in file is byte number 1.
  > > > 
  > > > Blech. I'd rather it were 0. No biggie.
  > > > 
  > > 
  > > Base 0 is fine for bytes but would be problematic for other ranges.
  > > E.g. 
  > > 
  > > 	http://host/book;chapterrange=3-5
  > > 
  > > would mean chapters 4 to 6 if base 0 is used.  This would be just too
  > > confusing.  We thought it better to be consistent and use the same
  > > base for everything.
  > 
  > I don't think this is relevant: http should be kept simple and data-type
  > independent, leave out the higher level semantics.  Then 0 based
  > addressing is the most sensible.  Even for chapters, the argument is
  > weak: what chapter number is the title page?  What chapter number
  > applies to appendicies?  Does the number then need to be a string that
  > names a sub-entity?  This is a Pandora's Box that should stay closed.

  As long as that sort of query at the _user level_ maps exactly, this is
  fine with me.  (I think that something akin to the above "chapterrange=3-5" 
  should actually mean what it seems to, at that level.)

  > 
  > Any thought on how this should interect with dynamic computed documents
  > (CGI-bin scripts)?  Supporting range addressing of computed documents
  > would require either re-computation on each fetch, or caching.  If
  > re-computed, how do you guarantee consistancy?  Imagine fetching a
  > document one byte at a time that contains the server's load average.


  Steve Richardson/Merit

Received on Monday, 22 May 1995 18:31:44 UTC