- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 14 Feb 96 16:48:49 PST
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-caching@pa.dec.com
> But a simpler approach would be to simply force reloading > in the rare cases where this kind of change is made at the > origin server. E.g., if "service" (the server and/or its > files) is modified to change the variant-selection algorithm > then all the cache validators for resources with variants > have to be changed as well. Either that, or use a different > (non-overlapping) set of variant IDs, so that the cached > copies associated with old variant-IDs would become stale > after 1000 seconds (or whatever). Again, this requires > no additional protocol mechanism, and this approach requires > no extra implementation complexity in the caches. Doesn't this have some implication for what you can choose as a 'cache validator' and expect it to work? That's a very good question, but the answer is "not a big problem." For example, if the validator or variant ID include some bits that are essentially an "epoch number", then the server can quickly either "change all the validators" or "change all the variant IDs" by incrementing the epoch number. It's probably entirely suitable to use a very small number of bits for the epoch number (and increment it mod 2^N) since this simply constrains the server not to go through this procedure very often. For example, if the epoch number has 2 bits and the maximum expiration time is 1 hour, you can pull off this trick every fifteen minutes or so. Note that you don't need to apply this epoch-based scheme to both the cache validator and the variant-ID. It suffices to apply it to at least one of them. It's a simplification to say that as soon as any one piece of information associated with a URI becomes stale, all of the rest of the information should become stale too. If we make that simplification, 'freshness' applies to "the URI's information" in general, rather than any particular piece of it. The problem that Koen points out is that this is not easily done, because a simple implementation of the variant-ID scheme allows repeated requests with one set of request headers to continually update the freshness information that applies to a different set of headers. -Jeff
Received on Thursday, 15 February 1996 01:04:15 UTC