Re: Issue List: CACHEDATE

Shel Kaphan wrote:

> David W. Morris writes:
>  > On Wed, 14 Feb 1996, Shel Kaphan wrote:

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

Let's look at this. The I-M-S date (ims) constructed by a requester could be in
three different intervals with respect to a Last-Modified time (lm) got from a
former request:

 ims < lm
	In this case the consistency of a GET request is always given, but the
	I-M-S header does not improve efficiency, if it was not computed using
	an old modification time.

 ims = lm
	This is the vanilla case. Everything works fine.

 lm < ims
	The document may have been modified in the time interval [lm, ims)
	and the output will be inconsistent from the requester's point of view,
	if there was a modification and the requester does *not* know about it.

Obviously, the critical case is the last one.

It is also obvious that a Date header's time (d) has always the property

  lm <= d	(1)

for a particular request message, which means that the document was not modified
in the time interval (lm, d].

If we compose a document from several parts with their own Last-Modified and Date
headers (lm1, lm2 ..., d1, d2 ...), then we can compute the following
Last-Modified date (lm) for the compound document:

  lm= min( d, d1, d2, ..., max( lm1, lm2, ...) )

with d equals the current time on the composing server. This trivially holds
equation (1) and ensures that a subsequent request for the same document using lm
as a I-M-S date (ims) will hold the following condition for all parts:

  ims <= di	for i of {1,2,...}

As the part i was not modified before di the client *knows* that there was no
modification in the interval [lmi, ims)!!

And that even holds when the clocks go years off!!! Of course, there is no
improvement of using I-M-S headers in this case because we tend to fall in the
ims<lm case (mentioned above), but the documents are always consistent.

If we assume that the clocks are almost synchronized the I-M-S date almost always
fullfils the following condition:

  lmi <= ims

which produces the desired efficiency improvement on 304 responses.


I addmit that there can be theoretical cases which cause problems:

 - A document is modified twice within a second (on a UNIX machine) and the server
   returns the first version.
 - A document is modified exactly at the time the document was returned by a
   server.

This may be the reason for introducing opaque validators, but it cannot be the
reason to change the I-M-S header treatment in the way it was proposed on the
issue list. Nevertheless, these race conditions are unlikely to occur.


> 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

Received on Thursday, 15 February 1996 03:12:57 UTC