Date: Wed, 17 May 1995 17:50:00 +0800 From: firstname.lastname@example.org (James Gosling) Message-Id: <9505180050.AA28623@norquay.Eng.Sun.COM> To: email@example.com, firstname.lastname@example.org Subject: Re: Byte ranges -- formal spec proposal Cc: email@example.com, firstname.lastname@example.org, email@example.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. 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.