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
cshotton@biap.com                                  http://www.biap.com/
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."

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