Publish Images a Shared Proxy Can Reuse
Give publicly reusable image responses an explicit freshness lifetime and validators, then interpret a browser reload separately from normal cache reuse.
For an image response carried through an HTTP-visible shared cache, publish an explicit lifetime and a validator. When the image is safe to reuse across users, example response headers are:
Cache-Control: public, max-age=604800
ETag: "image-v4"The lifetime is in seconds; 604800 is one week. Use public only for content intended for reuse across users.
If the browser and shared proxy need different lifetimes, s-maxage supplies the shared-cache lifetime. For example, max-age=3600 with s-maxage=604800 gives the shared cache the longer freshness period.
Expires is a date, not a duration
Expires takes an HTTP-date timestamp. max-age overrides that field, and s-maxage takes precedence for shared caches. Generate any Expires date when producing the response.
A reload can ask for validation
A request containing Cache-Control: no-cache asks for successful origin validation before a stored response is reused. That can happen even while the response's ordinary freshness policy would otherwise permit reuse.
The validator lets the cache check an unchanged image efficiently. A 304 response can confirm the stored representation without retransmitting the image bytes from the origin. Traffic to the origin therefore does not, by itself, mean the cached object was discarded.
Compare normal reuse and explicit reloads when reviewing the policy.