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

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)