In the absence of server-specified object expiration times, how should we set the cache's default TTL and how frequently should we ``get-if-modified'' versus simply returning the cached value? This question has several answers. Some service providers are contractually obligated to keep their cached data consistent: ``We promise to get-if-modified if the cached value is over 15 minutes old''. Others leave this question to the user and the brower's ``reload'' command. A quick study of Web data reveals that Internet object lifetimes vary widely and that no single mechanism will suffice.
To illustrate this, we periodically sampled the modification times of 4,600 HTTP objects distributed across 2,000 Internet sites during a three month period. We found that the mean lifetime of all objects was 44 days, HTML text objects and images were 75 and 107 days respectively, and objects of unknown types averaged 27 days. Over 28%of the objects were updated at least every 10 days, and 1%of the objects were dynamically updated. While WWW objects may become less volatile over time, the lifetime variance suggests that a single TTL applied to all objects will not be optimal. Note also that the time between modifications to particular objects is quite variable. This reinforces the need for picking cache TTLs based on last modification times, but that do not grow too large.
In the absence of object owner-provided TTLs, caches could grow object TTLs from some default minimum to some default maximum via binary exponential backoff. Each time an object's TTL expires, it could be revalidated with yet another get-if-modified.