- From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
- Date: Sat, 11 Nov 1995 19:22:00 -0800 (PST)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: montulli@mozilla.com, fielding@avron.ICS.UCI.EDU, ari@netscape.com, john@math.nwu.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Sat, 11 Nov 1995, Larry Masinter wrote: > Yes, byte ranges are GREAT! They're wonderful. We should definitely > have byte ranges in HTTP! It's a wonderful addition. Honest! Agreed... > They just don't belong at the end of arbitrary URLs. Maybe you want to > define a new URL scheme that calls out a new extension to the HTTP > protocol? Or a new HTTP method, as Roy Fielding suggested. But it seems to me that, looking at how Netscape Navigator 2.0 actually uses said byte ranges, there's a better solution. Namely, it uses them to get parts of PDF files, or to resume file transfers if disrupted. In each case, if the server does not understand the byte range, the web browser will respond with another request, one without the byte ranges. So why not cause this to be the default behavior, by adding a request header, something like Request-Range: bytes=500-999 The server, if it understood it, would respond as per draft-luotonen-http-url-byterange-00.txt (or whatever spec), and if not, it would just ignore it, being an unknown header, and simply return the entire document. It seems that the only reason to put the byte ranges into the URL is to allow a stand-alone URL to contain partial file information. However, I cannot envision a situation where this would be more useful than the browser-generated variety of byte range requests, a la Netscape Navigator 2.0. Thoughts? --/ Alexei Kosut <akosut@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC ----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/> The viewpoints expressed above are entirely false, and in no way represent Alexei Kosut nor any other person or entity. /--------------
Received on Saturday, 11 November 1995 19:25:29 UTC