W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Comments on Byte range draft

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
Message-Id: <9511111600.aa03577@paris.ics.uci.edu>
> 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.

Received on Saturday, 11 November 1995 16:08:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC