A stray Set-Cookie can waste your CDN: audit the cache at the edge

By Greg Nowak. Last updated 2026-07-27.

Putting a site behind a CDN does not automatically reduce the load on its origin. Cloudflare has to store a response and reuse it before any of that work disappears. One misplaced header can quietly prevent both.

Set-Cookie is a familiar culprit. Session middleware sometimes adds it to every response, even when a page contains nothing personal. Elsewhere, an application-wide default may send Cache-Control: private, no-cache or a zero freshness lifetime on public pages. The CDN is present, but the origin still renders and serves most requests.

Cloudflare's Cache Response Rules give teams another way to deal with this. Announced on July 23 for all plans, the rules run after Cloudflare receives the origin response and before it decides whether to cache it. Unlike a request-time rule, they can act on the headers and status the origin actually returned.

Find the wasted requests first

Do not begin by stripping headers across the site. Begin with the routes that keep reaching the origin, then work out whether that behaviour is accidental or necessary.

CF-Cache-Status provides an initial signal. HIT means Cloudflare served a stored object. MISS means the object was not in cache and had to come from the origin. BYPASS points to a response or configuration condition that prevented normal cache use. DYNAMIC means Cloudflare did not consider the resource eligible for caching under the applicable configuration.

One request will not tell you much. Review those statuses by route, response status, authentication state, request cookies and origin headers. Patterns are more useful: anonymous product pages that always bypass, documentation pages that never move from MISS to HIT, or an asset path whose behaviour changes after a deployment.

Put origin traffic beside the cache data. A busy public route that repeatedly reaches the origin because of the same response header is a credible performance and infrastructure-cost opportunity. A low-volume page, or one that genuinely varies by user, may be best left alone.

Route class	Default position	What to check	Sensible next move
Articles, documentation and landing pages	Good shared-cache candidates	Is global middleware adding cookies or restrictive cache headers?	Test a narrowly matched response rule, then repeat requests and look for `HIT`.
Versioned CSS, JavaScript, fonts and images	Good candidates for long freshness	Do immutable filenames and deployment practices support the configured lifetime?	Align edge freshness with versioning and confirm that purges still work.
Anonymous catalogue and listing pages	Possibly cacheable	Can location, currency, experiments, cookies or query parameters change the response?	Define the representation boundary before changing any headers.
Account, cart, checkout and admin routes	Normally private or bypassed	Could another user receive personal or sensitive information?	Keep these routes out of shared caching and test authentication boundaries.
Errors, redirects and temporary responses	Depends on status	Could caching prolong a failure, temporary redirect or incident?	Use explicit status-aware behaviour and conservative lifetimes.

A working route matrix for deciding where shared caching is appropriate and where it is not.

Shared caching creates a data boundary

A browser cache is private to one user. A shared cache can reuse a response for many users. That distinction turns cache configuration into a data-handling decision, not just a performance tweak.

RFC 9111 defines the rules for HTTP caching. The practical safety requirement is straightforward: a shared cache must not casually store or reuse a response that is private, depends on authorization or is otherwise unsuitable for a different user. MDN's caching guidance makes the same distinction between public and personalised content.

Removing Set-Cookie is safe only when the cookie serves no purpose on that route and the response is genuinely public. It is not a general workaround for session behaviour. Treat overrides of private and other restrictive Cache-Control directives with the same care. The origin may be applying an overly broad default, or it may be signalling a real privacy requirement. Establish which one before changing it.

A useful route inventory separates public anonymous content, authenticated pages, carts and checkout, administration paths, previews, API responses and static assets. It also records every request dimension that can alter the body: language, geography, device treatment, query parameters, authorization, consent, experiments and cookies. If two visitors can legitimately receive different content at the same apparent URL, the cache key and eligibility policy must preserve that difference.

Why the response phase matters

Traditional cache rules run before the origin response exists. They can match the incoming request and mark a route as cacheable, but they cannot inspect the status or headers returned for that particular response.

Cache Response Rules add a control point later in the exchange. Cloudflare documents operations covering cache-related response headers, cache-control behaviour and cache tags. A rule can therefore target the condition that caused the problem, such as an unnecessary cookie on a public route, while leaving authenticated or sensitive responses untouched.

This is especially useful when the blocker sits in legacy middleware, a platform cannot express different policies by route, or an origin fix is tied to a longer release cycle. The edge rule still needs to be documented as part of the application architecture. If the origin and CDN express different policies without a clear record, future debugging becomes needlessly difficult.

A controlled way to make the change

Build the baseline. Record request volume, origin traffic, CF-Cache-Status, response status, cache-control headers, validators, cookies, age and relevant request state for each route group.
Classify the responses. Confirm which ones are public and identical across users. Keep authenticated, personalised, cart, checkout, preview and administration traffic in separate safety domains.
Identify the actual blocker. It may be request-time ineligibility, the cache key, an origin response header, a status-specific policy or deliberate bypass configuration.
Write the narrowest useful rule. Match the required host, path, status and response condition. Change only the header or cache behaviour responsible for the accidental bypass.
Test both sides of the boundary. Exercise anonymous and logged-in requests, different cookies, query parameters, errors, redirects, previews and state-changing workflows.
Check the full content lifecycle. Verify that purges, deployments, content updates and cache tags invalidate the intended objects. Better reuse is no improvement if customers or editors receive stale content.
Compare the result with the baseline. Watch hit, miss, bypass and origin-request patterns, along with freshness, login behaviour, CSRF protection and application sessions.

A better hit ratio is not the whole job

Caching the wrong response is worse than bypassing it. The real objective is an arrangement that reuses public responses efficiently, keeps personal responses private and gives the team a clear explanation for the cache status of every important route.

Cache Response Rules can help teams with years of accumulated framework defaults and middleware behaviour recover wasted edge capacity without waiting for a broad origin rewrite. The work is still diagnostic: identify the routes that should be public, prove why Cloudflare is not storing them and correct only the accidental conditions.

This is a contained piece of operational work, but it crosses application behaviour, HTTP caching and Cloudflare configuration. A route-level audit gives the team a defensible rule set, a baseline for measuring the change and a practical test plan for keeping security and freshness boundaries intact.

Related on GrN.dk

Need help with this kind of work?

Plan a route-level cache audit Get in touch with Greg.

Sources

Last modified

2026-07-27