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

Re: Improving If-Modified-Since

From: James Pitkow <pitkow@cc.gatech.edu>
Date: Tue, 15 Aug 1995 13:00:16 -0400 (EDT)
Message-Id: <199508151700.NAA26038@hapeville.cc.gatech.edu>
To: Brian Behlendorf <brian@organic.com>
Cc: montulli@mozilla.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

  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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC