How a CDN cache answers a request
A CDN (content delivery network) runs caching servers in many locations, called points of presence. When a request arrives, the nearest server builds a cache key, usually from the host, path and query string, and looks it up. A hit is answered from the stored copy. On a miss, the CDN fetches the response from your own server, the origin, and stores it if the response headers allow.
Users reach a nearby location through anycast, where many locations announce the same IP address, or through DNS answers that point to a nearby server.
Response headers show what happened. The standard Age header gives the number of seconds a response has spent in a cache. Many CDNs add their own status header, such as X-Cache or CF-Cache-Status, and some use the standard Cache-Status header from RFC 9211.
Cache keys decide what counts as the same response
Two requests share a cached response only if they produce the same cache key. A key that includes too much fragments the cache, and a key that includes too little serves the wrong response.
Tracking parameters are the usual case of too much. By default, /pricing?utm_source=newsletter and /pricing?utm_source=ad are separate entries, and each one needs its own miss before it can be served from the cache. Most CDNs let you drop or sort query parameters that do not change the response.
Too little is the dangerous case. Suppose a response depends on something outside the key, such as a cookie, the Accept-Language header or the device type. The CDN can then serve one visitor's version to everyone who requests that URL.
Cache-Control for CDNs: max-age and s-maxage
The origin controls caching with the Cache-Control response header. Its max-age directive sets how many seconds any cache, browser or CDN, may reuse a response. The s-maxage directive overrides it for shared caches only, such as CDNs and proxies, so browsers and the CDN can keep a response for different lengths of time.
Some CDNs apply their own TTL settings instead of, or on top of, Cache-Control, so check how yours is configured. RFC 9213 also defines CDN-Cache-Control, a header that only CDNs act on. Typical values:
- Cache-Control: public, max-age=31536000, immutable suits files whose names contain a content hash, such as app.3f9c2a1.js. Browsers and the CDN keep them for a year, and a new version gets a new file name.
- Cache-Control: public, max-age=0, s-maxage=600 suits HTML pages that change when you deploy. Browsers revalidate on every use, and the CDN answers from its copy for 10 minutes.
- Cache-Control: private, no-cache suits personalized pages. The browser may keep a copy but must revalidate it, and a CDN must not store it.
- Cache-Control: no-store suits responses that no cache should keep, such as account details or pages that contain tokens.
Revalidation and purging
A stale copy does not have to be downloaded again. The CDN sends a conditional request with If-None-Match, carrying the response's ETag, or with If-Modified-Since. If nothing changed, the origin replies 304 Not Modified with no body, and the stored copy is fresh again.
Two directives from RFC 5861 soften expiry, where the CDN supports them. With stale-while-revalidate, the cache keeps serving the stale copy while it fetches a new one in the background. With stale-if-error, it serves the stale copy when the origin returns an error or cannot be reached.
Purging removes content before its lifetime ends: by URL, by tag on CDNs that support tags, or everything at once. Purges take time to reach every location, and purging everything sends a burst of misses to your origin.
A purge clears only the CDN. Browsers that stored a copy keep using it until their own max-age runs out, which is why HTML usually gets a short max-age and a longer s-maxage.
What not to cache, and how Vary changes the key
Keep personalized responses off the CDN. That covers anything that depends on a session cookie or an Authorization header, such as account pages, carts and API responses for a signed-in user. Mark them private or no-store at the origin instead of relying on CDN rules alone.
Be careful with Set-Cookie. HTTP caching rules do not forbid storing a response that sets a cookie, so a cached Set-Cookie can hand one visitor's session to everyone who receives that copy. Many CDNs skip such responses by default, but send Cache-Control: private or no-store with them anyway.
Rules that cache by file extension are risky too. If /account/settings.css returns the account page, which some frameworks do for unknown paths, a rule that caches every .css URL can store private data. This attack is called web cache deception.
The Vary header names request headers that change the response, and caches add those headers to the key. Vary: Accept-Encoding keeps compressed and uncompressed versions apart. Varying on a header with many values, such as User-Agent or Cookie, splits the cache into so many variants that most requests miss.