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

Re: Variant IDs

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 13 Feb 96 16:25:46 PST
Message-Id: <9602140025.AA05617@acetes.pa.dec.com>
To: koen@win.tue.nl (Koen Holtman)
Cc: http-caching@pa.dec.com
    Yes, but now for my original subtle question: what is the freshness of
    the two pieces of information
     "return variant 5 for User-agent: Blebber1.1"
     "return variant 5 for User-agent: Blebber2.2"
    that are stored by the cache?
    Presumably it is 1000 seconds for the first piece, but what about the
    second piece?  You can't just store such information forever, because
    if new bugs are found in Blebber2.2, the service provider may want to
    start mapping it to variant 6 instead.

Conceptually that's a good point, since without a somewhat more
careful approach, the expiration time for the cache entry could
be indefinitely extended by repeated validations due to
User-agent: Blebber1.1 requests.

One way to deal with this is to associate (internally to the
cache) separate expiration values with the variant as a whole
and for each of the cache-keys (which in this case would include
specific User-agent: values).  The former would be updated by
any 304 Not Modified response for the variant; the latter would
only be updated if the User-agent: fields actually matched.
This could be done with no additional protocol mechanism, but
it would make the cache implementation somewhat more complex.

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.

Later on in your message (regarding a different issue), you write:
   I think it is appropriate not to engage in prudent considerations
   about this kind of optimization for HTTP/1.1.

and I believe that the particular problem you describe is going
to be rare enough that it's not a big problem to use a brute-force
solution (of requiring caches to reload all the relevant resources).

Received on Wednesday, 14 February 1996 00:38:05 UTC

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