Re: Byte ranges -- formal spec proposal

On Thu, 18 May 1995, Chuck Shotton wrote:
> At 12:42 PM 5/18/95, Brian Behlendorf 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? 

Well, I thought Ari did, and since that's what he's working on at 
Netscape I thought that was the context.  I thought that was the whole 
point of making this a standard rather than leaving it up to each server 
to implement their own addressing mechanism; so that proxies that have a 
superset of a client's request can return that info directly without 
having to transfer what it already has.

> The proxy should pass the request and the resulting
> data through unadulterated to the client and it SHOULDN'T cache it. Ever.

Why not?

> These byte range requests should be treated like CGI requests, which should
> have the results of the request cached.

Huh?  How does a proxy server tell the difference between a CGI response 
and a flat file?  The only things proxy servers really care about are 
last-modified and expire times, and whether the request was for an 
authenticated product.  

What is wrong with the following: a user at demon.co.uk requests messages 
48-50 of a smtp-mailbox-format mailing list archive from a .jp host 
(using byteranges), and another demon.co.uk user wants message 49 (again 
using byteranges), so the cache at demon.co.uk does an if-modified-since 
to make sure the file itself hasn't changed, and upon confirmation of 
this plucks those byte ranges out of its local cache.  Please point out 
why this is a bad thing.

> >Now we get into some other subtleties - can we really reconstruct a
> >document from its fragments?  This seems to be the biggest selling point
> >of standardizing this whole thing - not only can a proxy that has
> >byterange 50-100 of a document serve up a request for byterange 60-80,
> >but if a proxy had 50-100 and 90-120, it could conceivably service a
> >request for 80-110 (*only* if the last-modified times matched though).
> >Okay, so doing this for byteranges isn't a big leap conceptually, but
> >what about for the other fragments proposed?  Can we do a similar
> >composition for lines, for paragraphs, for words?  Will "paragraph 3"
> >promise to be everything up to "paragraph 4"?  I guess this is a quality
> >of implementation issue.
> 
> I think we need some more examples to help illustrate Ari's immediate need
> for byte range requests. I know the genesis of this request and proposal (I
> think), and all of this extra baggage is not necessary or desired. Caching
> proxies need to step aside when a byte range request is sensed, and this
> needs to be treated as a dynamic data request between the client and
> server. The range data may be transient, dynamic, and may or may not have
> any relationship to a document that can be reconstructed in a file system.

Then that would be reflected in the last-modified or expires headers.  
Proxies today *are* designed to handle dynamic documents, at least, they 
are designed to be stand aside when the particular response tells 
them to do so.  

> We need to get over the file system paradigm in the HTTP world. This is a
> crippled model to be working from at best.

I agree with you - these are objects, with particular representations, 
and not always flat files.  Doesn't mean that we shouldn't have another 
way of addressing those representations.  If people were declaring 
byte ranges of representations to be their own single-representation 
objects, then that would be unfortunate.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Thursday, 18 May 1995 14:36:26 UTC