Re: I-D ACTION: draft-luotonen-http-url-byterange-00.txt
Larry Masinter (masinter@parc.xerox.com)
Wed, 5 Jul 1995 23:10:52 PDT
> 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'
headers?
> 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
ranges?
> 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.)