- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 18 Apr 96 15:27:27 MDT
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: http-caching@pa.dec.com
> 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.
That's too weak -- we definitely don't want people implementing
just a toggle and claiming compliance. How about
When the value changes, it SHOULD change to a value not already
used for that entity within a reasonable timeframe for which
there is likely to exist legitimately cached entities with the
same change-indicator value.
Vague, yes, but at least it makes the point.
How about this:
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.
Note: in order to provide semantically transparent caching, an
origin server should avoid reusing a specific strong opaque
validator value for two different instances of an entity, or
reusing a specific weak opaque validator value for two
semantically different instances of an entity. Caches entries
may persist for arbitrarily long periods, regardless of
expiration times, so it may be inappropriate to expect that a
cache will never again attempt to validate an entry using a
validator that it obtained at some point in the past.
That note is a little verbose, but I tried to make your point without
making the false implication that there is any way in HTTP to enforce
the timeframe you mentioned.
-Jeff
Received on Thursday, 18 April 1996 23:04:01 UTC