lifetime of validators

    >>   The change-indicator is used to indicate changes to the content of
    >>   the resource uniquely identified by the Request-URI and variant-id.
    >>   The change-indicator value SHOULD change when the content of an entity
    >>   changes and SHOULD NOT change when the content remains the same.
    >>   When the value changes, it MUST change to a value not already used for
    >>   that entity within a timeframe for which there may still exist
    >>   legitimately cached entities with the same change-indicator value.
    > 
    > As Jeff has pointed out in his more theoretical caching models, one can
    > legitimately store in cache memory a stale response forever.  So your
    > requirement above is better expressed as:
    > 
    >     When the value changes, it MUST change to a value not already used.
    
    No, the wording is correct as it stands -- the origin server can
    and will decide the scope of the timeframe.  In most cases, it will
    be "forever", but that is not necessary in the protocol.

While I'm sympathetic to Roy's position here, because I don't want
to overly restrict what an origin server can or cannot use as a
validator, I think it would be misleading to put that wording into
the protocol specification.  The reason is that Roy's proposed wording
is "correct" only in a situation where the origin server can either
(1) bound the lifetime of the validator value, or (2) know for sure that
all previous copies of that validator value have been extinguished.

I think it's pretty clear that (2) is impossible, since the origin
server cannot know what caches have received a copy of a response.
And (1) seems to be impossible in the existing protocol, since there
is no "expiration time" associated with the validator itself.

Even if a response has a max-age of, say, 1 minute, it's perfectly
allowable for a cache to store that response forever, as long as
it validates it before returning it to a client.

The only way to prevent this is to use "Cache-control: no-cache",
but then the validator isn't useful because the cache is not
allowed to do a conditional retrieval.

Unless someone seriously wants to propose something like
"Cache-control: max-validator-lifetime=NNN", there is no way
in HTTP to satisfy the premise of Roy's "timeframe" rule, that the
server can know the timeframe.   One could do this outside the
scope of the HTTP specification, in a closed system where the
caches are all managed by the same administration as the server,
but that is a rather special case.

At any rate, my compromise solution to this argument is to
say nothing about it in the spec.  That is, the specification
now says:
    In order to be legal, a strong opaque validator MUST change
    whenever the associated entity value changes in any way.  A weak
    opaque validator SHOULD change whenever the associated entity value
    changes in a semantically significant way.
and says nothing about when the values can be reused or not.  Maybe
we should include some "advice to implementors" about this later on.

-Jeff

Received on Tuesday, 16 April 1996 19:32:21 UTC