Re: Comments on Byte range draft

Chuck Shotton writes:
	...
 > 
 > It's not a matter of being "smart enough". It's a matter of whether or not
 > there is a BETTER solution that doesn't impose additional computational
 > overhead on the server side. For generated content, the content length
 > isn't known so you are saying that in addition to the normal operations
 > that a server has to do, when a byte range request is made it also has to
 > count all the bytes that it intends to emit and only emit the ones that
 > fall within a given range.
 > 
This is so cheap as to be, for all intents and purposes, free, and of
course you only have to generate the document up to the end of the
requested range anyway.  The meaningful savings is of network
bandwidth, which will way more than offset the cost of counting bytes.
(by several orders of magnitude).

 > 
 > First of all, I *don't* understand the "seriousness" of the problem. If a
 > user chooses to terminate a transfer, that was a conscious decision on
 > their part.

Sigh.  The "problem", and hence the savings, arise because often
people will go back to the interrupted transfer and re-request the
same things.  It then is much better to only have to ask for the part
you didn't get before.  It all boils down to being somewhat clever (and not
terribly) in order to save some network bandwidth, and some time for users.
There's nothing more to it than that.

	...

 > Let's get the goal straight once and for all. This whole byte range thing
 > originally came up last summer around the desire to serve portions of large
 > PDF documents. Are you saying that the issue now is the ability to resume
 > interrupted file transfers?

Let's *separate the issues* so you guys can stop flaming each other
and get on with your lives.  There's room for more than one issue in
the world, wouldn't you agree?

It's perfectly reasonable to want to have some "high-level" mechanisms
to request parts of structured objects.  Great.  But that is a
separate subject from this transport-level, efficiency-oriented
question that we are pursuing here.  OK?

 If so, then why are we dorking around with a
 > URL oriented solution? This screams for a modification to the GET method.
 > 
 > What you are saying is that you still want to retrieve a given URL (from
 > the client's perspective), but you'd like to GET only the portion you don't
 > already have. Rather like the if-modified-since header affects server
 > responses, a byte-range: header seems more appropriate than convoluting the
 > URL itself. I guess it's really just a matter of semantics, but all the
 > special punctuation, separators and other ca-ca that hang off the end URLs
 > could more easily be represented in many cases as header fields in a GET or
 > POST request.
 > 
	...

Yes, on this, at least, I agree with you.

Shel Kaphan

Received on Monday, 13 November 1995 15:43:09 UTC