- From: James Pitkow <pitkow@cc.gatech.edu>
- Date: Tue, 15 Aug 1995 13:00:16 -0400 (EDT)
- To: Brian Behlendorf <brian@organic.com>
- Cc: montulli@mozilla.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Hello, It seems like an obvious solution(??) is for the cache to throw out all timestamps greater than a given drift period from the current time. If I told you I did something in the future, would you believe me? I seems to recall a paper on that measured network clock drift, though it is most likely not valid now with all the PCs out there. Anybody else recall this paper? If so, we could get an empirical basis for drift. Jim. More generally, <Pine.SOL.3.91.950814215844.21140A-100000@eat.organic.com> from "Brian Behlendorf" at Aug 14, 95 10:14:22 pm > > If people "screw up their dates", they're hurting themselves and the people > who view their pages. This *isn't* accidental, is it? How do you > accidentally set a last-modified to be some future time? It's like a > surgeon accidentally removing a right leg instead of a left leg or a > disgruntled employee accidentally shooting his boss. > > Or maybe it's intentional... Most likely not. Just about all non-xntp systems need some human to administer - which means occasional ignorance. A lot of the future IMS headers I've seen result from misconfigured systems that have their internal clock set wrong. Nothing intentional, just their whole filesystem has yet to exist in a sense. > Okay, so what should a server do when it doesn't know the actual > content-length of an object, like a CGI script? It's totally plausible to > ask a dynamic object "hey, has any data upon which you would answer this > question changed since *blah*" in a way that's very quick to answer, but it's > hard to imagine asking it "hey, will your final output be any size > different than *blah*" without having it do what it normally does. So, > if it's in there, it must be optional for the server to use it. If a dymanic object's method has changed this ought to be knowable to the server either via the object's intrinsic properties or something like an inode (uglier). But this all assumes server-side execution, which for a lot of cases, can be transfered over to the client, so that only the methods/code get transmitted (stablier) For all but really cpu intensive jobs (probably don't want the world with access to those objects anyway), the network cost of transfer ought to out-weight execution, so the server retruning a simple hash suggestion seems reasonable.
Received on Tuesday, 15 August 1995 10:01:42 UTC