W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: Variant IDs

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 14 Feb 96 16:48:49 PST
Message-Id: <9602150048.AA11677@acetes.pa.dec.com>
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.

Received on Thursday, 15 February 1996 01:04:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC