- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Sat, 11 Nov 1995 16:00:27 -0800
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: ari@netscape.com, john@math.nwu.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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.
2) The Unlikely Way
Redefine a network PDF which allows easy inclusion of component
parts by URL reference rather than the traditional monstrosity.
3) The Partial Way
Define a new method PART and use that for partial GET requests.
....Roy
Received on Saturday, 11 November 1995 16:08:44 UTC