- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 13 Feb 96 16:25:46 PST
- 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" and "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). -Jeff
Received on Wednesday, 14 February 1996 00:38:05 UTC