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 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC