Re: Issue List: CACHEDATE

David W. Morris writes:
 > 
 > 
 > On Wed, 14 Feb 1996, Shel Kaphan wrote:
 > 
 > > I would claim that if you don't have the original last modified date of the
 > > document part that you have to fetch indirectly from another server,
 > > then you should not be using the conditional GET mechanism.
 > 
 > I would claim that this is application dependant.
 > 
Whether it matters certainly is.

 > > One problem is clock skew.  If only last modified dates are used in
 > > such requests, there is no issue with clock skew, because the only
 > > clock in question is the origin server's.  If the I-M-S date in the
 > > request is constructed by the requestor, then any difference between its
 > > clock and the server's clock may make the server do the wrong thing.
 > > Whether this matters or not is application dependent.  This is one of the
 > > reasons I tend to prefer the "opaque validator" approach.
 > 
 > Well history pretty much dictates that I-M-S is here. It doesn't make much
 > sense to me to invalidate existing implementations by defining a 
 > non-obvious interpretation of I-M-S as a back door way to introduce
 > "opaque validators" (which I favor as well). Let both co-exist and let the
 > content provider decide which makes sense. 
 > 

I didn't think I was suggesting invalidating existing implementations
(they can take care of that for themselves!), only pointing out a way
in which there can be obscure problems with the existing I-M-S
mechanism.  It's an obscure example, but it does have problems (both
the race condition and the skew possibility) The skew problem for
constructed I-M-S dates has always been, in my mind, one of the
justifications for opaque validators.  It shows that there are
problems when clients innocently think they can use the mechanism in a
way it isn't designed to be used.


 > Clock skew can be completely factored out if the client simply uses the
 > Date: of the response serving the value for its I-M-S value.
 > 
In this example, the "client" (which was the server constructing the
compound document) no longer had the Last Modified date of the part it
needed to re-fetch.  So let's say it no longer had the Date either...
as I see it the problem is that the apparent semantics of the mechanism
make it too tempting to use it in ways that have subtle failure modes.
The realistic things that can be done are: (1) put appropriate caveats
in the description of I-M-S, and (2) provide the alternative opaque
validator mechanism that we've been working on.

 > Any I-M-S value >= the actual LMDate should return 304.  Include some 
 > warnings about the risks of arbitrary dates. I don't think it would be
 > unreasonable for an implementation to store the cached copy and use the
 > caching file system date to record the LMDate. But if the server is UNIX
 > with one second resolution and the client WINDOS with 2 second resolution
 > 1/2 of all dates won't exactly match. But always rounding the WINDOS date
 > coversion UP 1 second is safe enough for all practical purposes.
 > 
 > Dave Morris

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.  

--SHel

Received on Thursday, 15 February 1996 02:03:27 UTC