v0.32.2

docs/CACHE.md

@@ -30,11 +30,19 @@ Vhost response rules run before cache fill, and transformed output is what is
 stored. Private/`Set-Cookie`/`no-store` origin responses remain ineligible,
 even if a later response-header rule replaces their visible cache headers.
 
-For Web Server sources, stale entries are refreshed by a new local-source
-request rather than the remote-backend revalidation worker. As with reverse
-proxy origins, range requests and conditional requests can reuse fresh stored
-representations. Do not rely on stale-if-error remote-backend refresh behavior
-for local Web Server routes.
+For Web Server sources (0.32.2), requests with `Cache-Control: no-cache`,
+`max-age=0`, or an expired/inadequately fresh representation check the local
+origin using the stored origin `ETag` / `Last-Modified`. When the Web Server
+returns `304 Not Modified`, RustProxy refreshes the same shared-cache object,
+keeps its body and increments `X-Cache-Hits`. The original browser conditional
+headers determine whether the client receives 304 or the cached 200 body.
+Changed static files cause a new response/cache fill; `no-store`/`private`
+origin policy continues to prevent shared storage. HEAD and single-range
+requests can reuse a successfully revalidated full object. A Web Server
+source does not run the remote-backend background revalidation worker or its
+stale-if-error fallback. A PHP handler that ignores validators may still
+return 200, which must be handled as a real origin response rather than an
+assumed unchanged object.
 
 ## HTTP BAN / PURGE from authorized client IPs