Re: Issue List: CACHEDATE

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.

> 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. 

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.

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

Received on Wednesday, 14 February 1996 23:20:48 UTC