Concept and mechanism
A cache stores responses for reuse under defined conditions. Unqualified no-cache requires successful validation before reuse; it does not necessarily forbid storage. no-store instructs caches not to store but does not magically erase previous copies or replace all security controls. private restricts storage by shared caches while potentially permitting private caching under the remaining rules. Do not confuse the term with user authentication. Proxy configuration can contradict what the application emits, so effective fields and applied rules must be observed. Policy should match the actual sensitivity and variability of the content.
Guided application
In a fictional case, two identities receive the same personalized representation because a cache keys only by URL and ignores private. Contain exposure, invalidate affected entries, and validate the correction with distinct identities. Adding a future directive does not establish that old content disappeared. For language variants, Vary: Accept-Language allows considering that field during selection; it is not access authorization. A conditional GET using If-None-Match can receive 304 when the appropriate stored representation remains valid. The client updates applicable metadata and reuses the existing body. Replacing it with an empty body confuses missing content in a validation response with missing resource data.
no-cache requests validation; no-store requests no storage; private prevents shared-cache storage.
Common pitfalls
no-cache as no-store; a new directive as purge; Vary as authorization; 304 as an empty resource.
Related topics: The request and intended representation · Methods, statuses, and controlled retries · Versions and message framing
Validate who may reuse each representation, under which conditions, and with what evidence.
Reference: HTTP Caching · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance