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

Re: Byte ranges (was Re: Logic Bag concerns)

From: Mike Braca <mb@ebt.com>
Date: Sat, 02 Dec 1995 08:49:56 -0500
Message-Id: <30C05984.5ECD@ebt.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: Ari Luotonen <luotonen@netscape.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul wrote:
> In other words, IN ALL CASES what the cache-validator means is
> that if it doesn't match, send the whole object.  What Range:
> modifies is the behavior of GET when the cache-validator does
> match.  And (if you like) you can think of a missing Range:
> header as implying "Range: bytes=0-0", so there is really only
> one meaning.

(I assume you meant "Range: bytes=0-")


> Maybe it's simpler to think about this if you pronounce
> "GET" as "Make sure my cache for this object is up to date".

Well, yes, but an empty cache is just as valid as one full of
up-to-date objects :)

I hate the notion of automatically dumping the whole file onto the net.
First of all, it is not intuitive to an ex-OS hacker like myself that
if something in the cache goes stale, I reload the whole (file,...)
instead of simply flushing the object from the cache.  More
pragmatically, we are working on displaying potentially huge SGML
documents via HTTP, and if a 20 MB file that I am pulling subtrees
out of gets changed, I don't want to trigger a send of the whole file.
Perhaps Ari can tell me how they plan for this to work in the PDF
case -- I may be missing something obvious here!

What would make sense to me is to define something like a
"305 Modified" response that passes me back the new cache-validator.
Then _I_ can decide whether to fetch the whole file, or an index or
whatever. What are the drawbacks to such a scheme?

Mike Braca
Wasabe Software, Inc.
(Currently at mb@ebt.com)
Received on Sunday, 3 December 1995 21:26:29 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:36 EDT