Re: Issue List: CACHEDATE

Franz J. Hauck writes:
 > > I didn't think I was suggesting invalidating existing implementations
 > > (they can take care of that for themselves!), [...]
 > The proposal on the issue list does exactly this.
 > > The kind of case that seems likely to break is a client with a clock
 > > that's relatively out of whack (say, 5 minutes off, like the Mac I'm
 > > writing this on), an application that depends for correctness on
 > > clients always validating documents, and client software that
 > > (for some reason) is doing unspeakable things to construct I-M-S dates
 > > based on its own clock, thereby causing the application to appear to
 > > be broken.
 > I think, I have shown that this is *not* true.
 > -- Franz

You've shown that by being sufficiently conservative with the I-M-S date
you can avoid some problems in the compound document case you mentioned.

Let's just think about one client and one server.  If the client's
clock and the server's clock differ, and the client uses its own clock
to generate I-M-S dates that are in the future relative to the
server's clock, or even I-M-S dates that "skip over" the actual LM
date of the resource in question, then the client can miss changes to a
document.  Whether this is something that matters or not depends on
the application.


client	server
clock	clock

0:05	0:00		server serves document.
0:09	0:04		document is modified on the server.
0:15	0:10		being stupid, client send GET I-M-S 0:05.
			server responds with 304.			


Received on Thursday, 15 February 1996 09:12:32 UTC