Re: An alternative to explicit revocation?

    >	Volume-ID: <opaque string>
    >	Volume-version: <opaque-string>
    >	Volume-expiration: <date> (or maybe <offset in seconds>?)
    
    I could handle a less verbose syntax:
    
	    Volume: <id> <version> <date-in-YYYYMMDDHHMMSSZ-format>
    
I certainly could live with shorter header names (VID:, VVer:, Vexp:)
but I think it might pay to keep these as separate headers, since
the Volume-version and Volume-ID have to be kept in the per-resource
cache entry, but the Volume-expiration need not be.  Or maybe this
is easy enough to implement either way.

   Date parsing: Just Say No!

Actually, I spent part of the weekend mulling this over, and I
think the use of absolute expiration dates (as opposed to "seconds 
remaining") is a mistake.  Not that I propose changing Expires:,
but rather to use a new header for the purpose of managing
cache "freshness" lifetimes.

Consider the problem of dealing with clock skew.  Originally,
some of us (including me) thought that this could be handled
using the Date: header, but since that is generated at the origin
server, if there are multiple caches in the request chain (and
hence more than two clocks), this becomes quite tricky.

Think about how you would handle this case:

	The origin server has a correct clock.  On Monday,
	it generates a response which is cachable until Friday.
	
	The first cache has a clock that is a day slow (it
	thinks it is Sunday), so it applies the clock-correction
	algorithm and decides that the resource is safe to
	cache until Friday according to its own clock, which
	is Saturday in real life.
	
	Later, the second cache requests the resource
	from the first cache.  How does it detect that the
	second cache has a bogus clock?  It can't use the
	Date: header, since this came from the origin server.
	And it cannot tell the offset between its own clock
	and the origin server, because the Date: value could
	be new or it could be many days old.

One have the caches rewrite the expiration dates, or include
more mechanisms for clock-deskewing.  But it seems much simpler
and safer to express expiration as a number of seconds remaining,
which works as long as the inaccuracy in clock rates is reasonably
small.  (I can easily set my watch to the wrong time; it's harder
to get it to tick at the wrong rate.)

-Jeff

Received on Wednesday, 3 January 1996 00:51:48 UTC