I've been investigating making a patch that allows HTCP CLR and the purge method to invalidate all stored variants of a given URL. The two possible basic approaches in this situation are:
* Cascading update. Store a list of variants in the base vary object and delete all of them when requested. * Invalidation. Delete the base vary object without cascading. It may be subsequently recreated. On retrieval of a variant, check if it is older than the base vary object. If it is, delete the variant from the store and pretend (for the remainder of the request) that it never existed. I believe invalidation is best, since updates are fast and simple, and there is no performance penalty on retrievals except for cases when deferred storage deletion is required. The problem is that there appears to be no suitable timestamp stored, which we can use for this comparison. The StoreEntry->timestamp field, which is stored in STORE_META_STD, is just an adjusted version of the Date header. It doesn't reflect the local creation date, rather, it is an estimate of the origin generation date. It is referenced in many places for expiry calculations. There is no actual need to use a timestamp: a random GUID or serial number would work just as well. And in fact the one-second resolution of a typical timestamp could cause problems if a page is updated twice in the same second. If squid has no facilities for random GUIDs or persistent serial numbers, then current_dtime might be the best option. So my proposal is to add a new metadata item to storage objects, called say STORE_META_CREATE_DTIME. It could store the timestamp in machine double-precision format or some machine-independent format, depending on the preference of the list. Any comments? -- Tim Starling
