- 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
> 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.)
Received on Wednesday, 5 July 1995 23:12:16 UTC