HTTP Caching

Why it matters

Caching makes repeat visits fast and takes load off the servers, but every cached copy can be out of date or reach the wrong person. Typical defects: an old price or an old script after a release, a page in the wrong language, and the worst kind, a shared cache that serves one customer's account page to the next customer.

Test environments often lack a CDN, and testers often work with DevTools' "Disable cache" switched on, so these defects surface in production unless someone reads the caching headers before release.

Fresh or stale: what Cache-Control decides

A cache stores a response under a cache key made of at least the request method and the URL; most stored responses are successful GET responses. While a stored response is fresh, the cache may reuse it without contacting the server. Once it is stale, the cache normally has to check with the server first.

The freshness lifetime comes from max-age, or else from the older Expires header, which holds a fixed date and is ignored when max-age is present. With neither, a cache may guess a lifetime (heuristic freshness), often from Last-Modified. So a response without caching headers is not "uncached", only unpredictable.

• max-age=600: fresh for 600 seconds. s-maxage sets the lifetime for shared caches only.
• no-cache: may be stored, but must be revalidated with the server before every reuse. Despite its name, it does not forbid caching.
• no-store: no cache may store the request or the response. This is the directive for personal and sensitive data.
• private: only the user's own (private) cache may store it. public: any cache may, even where it otherwise would not.
• must-revalidate: once stale, the copy must not be used without a successful check, even if the server is unreachable.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60
ETag: "p1042-v7"
Last-Modified: Wed, 30 Sep 2026 08:00:00 GMT
Date: Thu, 01 Oct 2026 09:00:00 GMT

Try it: Cache Header Analyzer Try it: HTTP Header Builder

Revalidation: ETag, Last-Modified and 304

To check a stale copy cheaply, the server labels each response with a validator: ETag, an opaque version tag such as "p1042-v7", or Last-Modified, a date. The cache sends it back in a conditional request: If-None-Match for the ETag, If-Modified-Since for the date. When both are present, RFC 9110 tells the server to ignore If-Modified-Since.

If nothing changed, the server answers 304 Not Modified: no body, only headers such as ETag, Cache-Control and Date, which refresh the stored copy that the client then shows. If the resource changed, it answers 200 OK with the new body and a new ETag. An ETag starting with W/ is weak: it promises equivalent content, not byte-for-byte identical content.

GET /api/products/1042 HTTP/1.1
Host: shop.example
If-None-Match: "p1042-v7"

HTTP/1.1 304 Not Modified
Cache-Control: max-age=60
ETag: "p1042-v7"
Date: Thu, 01 Oct 2026 09:01:05 GMT

Try it: cURL Generator Try it: HTTP Headers Parser

Shared and private caches

A private cache serves one user, normally the browser. A shared cache stores responses for many users: a proxy, a CDN or a reverse proxy in front of the application. RFC 9111 protects one case by default: a shared cache must not reuse a response to a request that carried an Authorization header unless the response allows it, for example with public or s-maxage.

A session cookie gets no such protection, so a personalised response must itself say private or no-store. In the lesson on authentication and authorization you checked who may see which data; a shared cache is one more way for the wrong person to see it.

• Vary names the request headers the response depends on, such as Vary: Accept-Language. Without it, a shared cache can serve the Arabic page to someone who asked for English.
• A successful POST, PUT or DELETE invalidates the stored copy of that URL only in the caches the request passes through; other caches keep theirs until it goes stale or is purged.
• An Age header means the response came from a cache. Many CDNs also add their own header that reports a hit or a miss; its name depends on the vendor.

Worked example: testing a product page behind a CDN

A store serves its product pages through a CDN. Rules: a new price must show within one minute, and account pages must never be cached. Turn the rules into expected headers for each type of response, then test the behaviour with repeatable requests (curl, the API tools or the DevTools Network panel), noting how each page was loaded: link, reload or hard reload.

• Versioned file such as app.3f9c1a.js: a long max-age is correct, because every release gets a new file name.
• Product API with max-age=60 and an ETag: repeat the request with If-None-Match and expect 304 with no body. Change the price, wait 60 seconds, repeat: expect 200, the new price and a new ETag.
• Through the CDN: send the same request twice and check that Age appears and grows. Then send it with Accept-Language: ar and with en and compare the bodies.
• Account pages: expect no-store. Open the same orders URL as customer A and as customer B in two browsers; B must never see A's orders. After logout, Back must not show private data; test this in each target browser, because RFC 9111 does not require the browser history to follow caching rules.

Try it: API Header Validator

Frequently asked questions

References

• RFC 9111: HTTP CachingIETF · 2022How Cache-Control, Expires, ETag and validators decide whether a response may be stored and reused.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• HTTP caching — MDNMDN Web Docs (Mozilla)Private vs. shared caches, freshness, validation with ETag / Last-Modified and the common Cache-Control patterns.
• OWASP Cheat Sheet Series: Session ManagementOWASP FoundationSession identifier entropy, cookie attributes, expiry, renewal after login and logout handling.