- From: Lou Montulli <montulli@mozilla.com>
- Date: Sat, 11 Nov 1995 17:50:27 -0800
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: Larry Masinter <masinter@parc.xerox.com>, ari@netscape.com, john@math.nwu.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Roy T. Fielding wrote:
>
> > I suggested before and will suggest again that byte ranges do not
> > belong in URLs, since the results are not in fact any of the media
> > types that were identified in "accept:" or are likely to be reported
> > by content-type, and that byte ranges are likely to become incorrect
> > if the original data for which the range was valid is replaced with a
> > new version which does not exactly correspond byte-for-byte by the new
> > structure.
> >
> > It is a category error. If you want to refer to a part of a structure
> > by name or structural tag, that would at least be more robust ("give
> > me the catalog of this PDF document, or give me the data for page 1").
>
> I'll second this. I tried to work this stuff into the framework of
> HTTP and it just doesn't fit as currently described. My conclusion is
> that there are only three ways to do what you want:
>
> 1) The Right Way
>
> Treat all PDF files as a tree, containing a catalog of pages,
> chapters, or whatever other components can be identified within
> the PDF. Assign each of these components a URL and make the server
> smart enough to extract the right component.
>
You and Larry are looking at this problem with blinders on.
There are many more uses for byterange URL's than simply
PDF files. For instance Netscape 2.0 uses byteranges to
request parts of files that it didn't get the last time
you came to a page. You can therefore interrupt a page
during download at any time and continue it exactly
where you left off when you come back to the page. This
makes cachine up to 50% more effective at saving bandwidth.
:lou
--
Lou Montulli http://www.netscape.com/people/montulli/
Netscape Communications Corp.
Received on Saturday, 11 November 1995 17:54:57 UTC