v0.26.7

docs/CACHE_DIAGNOSTICS.md

@@ -42,14 +42,20 @@ explicit invalidation.
 These are different clocks:
 
 - `Age` is HTTP freshness age. It can already be thousands of seconds when RustProxy
-  receives an object because the origin/CDN `Date`/`Age` contributes to it.
+  receives an object because the origin/CDN `Date`/`Age` contributes to it. On an ordinary
+  fresh HIT it advances from RustProxy's stored receive time even when the backend never
+  supplied an `Age` header. A successful validator revalidation (backend `304`) starts a
+  new freshness calculation, so the next `Age` can legitimately be `0`. Requests carrying
+  `Cache-Control: no-cache`, `max-age=0` or `Pragma: no-cache` can therefore make repeated
+  validated HITs appear with `Age: 0`.
 - `X-Cache-Resident-Age` is RustProxy-specific and counts whole seconds that the stored
   representation has remained resident in this cache.
 
-In 0.11.5 resident age is preserved across a successful backend 304 and across
-hot-to-cold/cold-to-hot movement. An immediate first HIT can legitimately show `0`
-because less than one full second has elapsed; a long-lived object should then keep
-increasing rather than repeatedly resetting to zero.
+Resident age is preserved across a successful backend 304 and across hot-to-cold/cold-to-hot
+movement. An immediate first HIT can legitimately show `0` because less than one full second
+has elapsed; a long-lived resident object should then keep increasing rather than repeatedly
+resetting to zero. Use this header when the diagnostic question is cache residency rather than
+HTTP freshness.
 
 ## Practical HIT test