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

Re: I-D ACTION: draft-luotonen-http-url-byterange-00.txt

From: Larry Masinter <masinter@parc.xerox.com>
Date: Wed, 5 Jul 1995 23:10:52 PDT
To: luotonen@netscape.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <95Jul5.231053pdt.2762@golden.parc.xerox.com>
>  There are a number of Web applications that would benefit from being
>  able to request the server to give a byte range of a document. As an
>  example an Adobe PDF viewer needs to be able to access individual
>  pages by byte range; the table that defines those ranges is located
>  at the end of the PDF file.

Unfortunately, the example you give doesn't work in a straightforward
way. If you expect the client to know that the PDF file is to be
retrieved in parts, should the parts be labeled
application/octet-stream? In what way is the object which is
supposed to be GET using HTTP to be distinguished with 'accept'

>  It may be argued that this should be left as a server-specific
>  feature in the opaque URL, as the "parameters" used in URLs that may
>  be available or useful can vary from server to server. However, there
>  are reasons why standardizing the byte range feature would be
>  beneficial.

Except that in the examples you give, these partial fragments would
not be treated as URLs, again for the reason that a byte range of a
part of a file is not of the same type as the entire file.

>  One of the primary reasons is to be able to support byte ranges in
>  proxy servers. Without a standard proxy servers will have to treat
>  each different byte range of a given document as a separate document.
>  Should the notion of a byte range be standard, not only would it
>  prevent portions of documents to be multiply cached, but it would
>  make it possible for the proxy to generate range responses directly
>  from its cache, and reassemble the entire document from the pieces.
>  This specification is simple enough to be adopted quickly by the
>  server authors/vendors, and be quickly and easily exploited on the
>  client side.

You give no examples of how this can be 'exploited' on the client
side, leaving it to the imagination of the reader. There are currently
no 'non-standard' examples of this. If this is useful to be a standard
and can be done without a standard, wouldn't there be some instances
of servers that use byte ranges?

In what way is the merging of multiple byte ranges by a proxy server a
benefit? Why would one client retrieve one set of byte ranges and
another retrieve a different set? How would clients know to use byte

> Syntax of the "bytes" URL Parameter

It doesn't matter as much, but you should note that the syntax
modifies RFC 1738 in that it 'reserves' the : character within HTTP
URLs (which previously was not reserved), and, for that matter, "-"
and "," (unless you want to allow - and , to be URL encoded.)
Received on Wednesday, 5 July 1995 23:12:16 UTC

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