Re: Comments on Byte range draft

Chuck Shotton wrote:
> >This is a severely broken behavior by a server. And IRRELEVANT. Since
> >byte range requests are not recognized by todays servers - you obviously
> >cannot break one by insisting the damn server keep its hands off the
> >content if it support byte range requests. IOW: Find another red herring
> >to drag.
> 
> Oh, servers that do ISO translations, Shift-JIS translations, or line end
> translations that conform to the MIME standard are "severely broken?"
> Methinks not. Perhaps you should study the available range of servers out
> there before dismissing this particular issue as a "red herring." Server
> side document translation is a HUGE issue, and many servers support it. The
> point that the local storage representation of a document is not the same
> as the content transmitted to a client is a very real and valid one.
> Overlooking this issue or dismissing it shows a very narrow understanding
> of server implementation issues and the state of server development as it
> exists today. Please take a little more time to understand what is going on
> here before you unilaterally decide that your position is correct.

If your server wishes to compute data on the fly then that's fine. 
Ari's byterange proposal allows the server to specify explicitly 
which objects are byterange seekable and those that are not.
Since your server is not smart enough to be able to compute a 
byterange, you can simply keep byteranges off.

> >[deleted special purpose solution for PDF documents]
> >
> >Pull the blinders back off. IGNORE PDF. There is a general problem with
> >restarting partially transmitted documents that that is just a special
> >case of. We need a method of saying *for any document what-so-ever*:
> >"Send me bytes 10000 through 20000".
> 
> I would turn the problem around by asking you why clients only have partial
> documents to contend with? You seem to want to implement Zmodem file
> transfers on top of HTTP, with the ability to resume an interrupted
> transfer. The net is not a modem connection. TCP/IP is ostensibly a
> reliable delivery mechanism. You either get all the data or you don't. So,
> why are you getting partial files? Is your client broken? If so, that
> doesn't seem to warrant a change to the URL standard to fix it. Is the
> server broken? Ditto. Is your net connection flakey? Again, not a HTTP or
> URL problem.
> 
> If the issue is to deliver portions of an entire document because that
> portion is a recognizably distinct object that the browser can deal with, I
> say let the server specify how those parts are to be requested and
> delivered. This is a much more rational, useful reason for byte range
> extensions to exist. Trying to justify them with some specious argument
> about resumed file transfers is perhaps the biggest red herring of all.

You seem to be content with ignoring the fact that users interrupt transfers
on nearly every heavily laden graphical page they visit.  This causes many
many valid partial transfers to occur.  If you want to sit around and ignore
the issues users are having trouble with that's fine, but don't try and
block a perfectly valid solution to a very serious problem.

:lou
-- 
Lou Montulli                 http://www.netscape.com/people/montulli/
       Netscape Communications Corp.

Received on Monday, 13 November 1995 14:55:55 UTC