v0.28.0

docs/CACHE.md

@@ -55,6 +55,7 @@ behavior exactly.
 | expose_hits | false | Emit per-object `X-Cache-Hits` |
 | expose_cache_status | false | Emit standardized `Cache-Status` (RFC 9211) |
 | expose_resident_age | false | Emit `X-Cache-Resident-Age` on reused stored responses |
+| via_header | `RustProxy` | Append this `Via` response value; `null` disables it |
 | collapse_enabled | true | Collapse concurrent foreground fills for the same primary cache key |
 | collapse_wait_timeout_ms | 1500 | 10..60000 ms follower wait before fallback |
 | collapse_timeout_fallback | origin | `origin` or `stale_if_available` after follower timeout |
@@ -148,7 +149,7 @@ Cache invalidation remains explicit:
 - BAN records a bounded TTL rule without synchronously scanning the entire store; objects created before a matching active BAN are rejected during lookup/insertion and are removed later by bounded GC,
 - new fills created after a BAN rule are allowed, so BAN invalidates the old representation set rather than permanently blocking a URL,
 - regex rules and prefix `/` are treated as broad operations and require explicit confirmation,
-- only cache-compatibility changes (cache policy, configured header/origin semantics or vhosts) advance the normal cache generation/revision; unrelated logging/TLS/admin/metrics/response-presentation saves retain objects.
+- only cache-compatibility changes advance the normal cache generation/revision; unrelated logging/TLS/admin/metrics/response-presentation saves retain objects, and cache request-bypass edits plus response-only `X-Cache`/`Cache-Status`/resident-age/`Via` diagnostics also apply without purging stored objects.
 
 There is no public unauthenticated PURGE/BAN endpoint. If an application changes a GET
 resource after POST/PUT/PATCH/DELETE, use origin freshness/validators or the authenticated
@@ -272,7 +273,7 @@ bytes. Purge-all and purge-vhost remain the full-clear mechanisms; selective inv
 is deliberately separate.
 
 `X-Cache`, `X-Cache-Hits`, `Cache-Status`, `X-Cache-Reason` and
-`X-Cache-Resident-Age` are optional diagnostics. `Cache-Status` is the standardized
+`X-Cache-Resident-Age` are optional diagnostics. `Via` is a separate configurable response header, enabled by default with value `RustProxy`; RustProxy appends it instead of deleting an upstream `Via` chain. `Cache-Status` is the standardized
 RFC 9211 field name; RustProxy does not rename it to the legacy/custom `X-Cache-Status`.
 HTTP/2 and HTTP/3 serialize field names in lowercase, so `cache-status:` on the wire is
 normal. When the cached representation was produced by the transform pipeline,