Re: Byte ranges -- formal spec proposal

At 1:53 PM 5/18/95, Ari Luotonen wrote:
>> >Well, we do have to settle on a standard though, since we're going to
>> >rely proxy servers to reassemble full documents from byte ranges.  At
>> >least that was my interpretation of Ari's proposal - the proxy needs to
>> >know if "1-end" means the complete document or not.
>> Says who? Who said anything about proxies trying to be cute in the middle
>> of byte range requests?
>Says me.  The second paragraph of the proposal indicates that making
>proxies aware of this is one of the primary reasons why this standard
>should exist.

Well, mark me off for poor reading comprehension. :)

>We're talking about potentially HUGE documents, which is the very
>reason why byteranges make sense with them.  So caching them, and
>possibly reconstructing them from pieces, is a big win, and not doing
>that would be really silly.

So, how do you deal with multi-fork files, byte ranges from generated
output streams, ranges that are interpreted as records in a database or any
other number of problems? It certainly complicates the caching of this
stuff. Also, how can a proxy be expected to reconstruct a document from a
sparse set of byte range requests (e.g, 1-100, followed by 45000-45100,
followed by 3000-3300, followed by 99-45001)? I understand your motivation
here, but proxy implementation is going to be a nightmare if you really try
to build it this way.

>The spec is written so as to make this work through existing proxies
>without support for it, to intentionally break with servers that don't
>have support for it, and to make it work in clients without adding
>more interaction and complexity between HTML and HTTP.

What do you mean by "intentionally break" with servers that don't support it?

Chuck Shotton                                                   "I am NOT here."

Received on Thursday, 18 May 1995 14:32:07 UTC