W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1995

Re: Comments on Byte range draft

From: Benjamin Franz <snowhare@netimages.com>
Date: Mon, 13 Nov 1995 08:53:19 -0800 (PST)
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.91.951113084437.166C-100000@ns.viet.net>
On Sun, 12 Nov 1995, Gavin Nicol wrote:

> >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".
> Wrong. We need a method of saying "Send me pieces n to m". 
> BTW. Your argument that EOL conversion by servers is "badly broken" is
> also wrong. I fully expect to see servers capable of coded character
> set and encoding translation appearing in the very near future. For
> such servers, byte ranges are simply BAD (Broken As Designed), because
> a byte might no longer be the atomic unit of information, and because,
> as Chuck pointed out, the server would have to convert *everything*,
> and then select the piece requested.

On consideration - the EOL conversion issue is just another red herring. 
It simply doesn't matter to the question of byte ranges. Byte ranges 
*clearly* should apply to the transmitted byte stream - not the server side 
representation of said byte stream. And one way or another the byte 
stream is *always* generated. And unless your conversion is 
non-deterministic the byte-stream will always be the same from the same 
source document for a given GET request. The byte is inherently the 
atomic unit of information in HTTP. What connects a server to a client 
*is* a byte stream. End point representations of that byte stream 
should be completely irrelevant to the issue of byte ranges.

Benjamin Franz
Received on Monday, 13 November 1995 08:46:30 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC