Removing Set-Cookie does not remove a personalized body
Cache Response Rules can fix an origin's stray headers. Sharing the resulting body still needs a clear public-content contract and an accountable owner.
By 
Paul. Architecture and infrastructure
Removing a header can make a response eligible for a shared cache while leaving its personalized body untouched. That is the distinction a team needs to settle before overriding an origin's caching instructions. The safety claim concerns the selected content and everyone who may receive it. A cleaner header is evidence of a header change, not proof of that broader claim.
Cloudflare's 23 July 2026 Cache Response Rules announcement describes rules that run after the origin replies and before cache storage. They can strip specified headers, manage cache tags and modify cache-control directives. Looking back in November, the architectural question is who owns the promise that a response selected by such a rule is public.
The timing gives control a boundary
The announcement distinguishes request-stage decisions from response-stage adjustments. The response phase cannot change the already selected cache key or make a previously ineligible request eligible. In conflicts over cache settings, the response rule takes precedence. Those limits matter when reviewing a proposed change: a response rule has a specific place in the path, rather than unlimited authority over every caching decision.
The earlier Workers Cache announcement from 6 July supplies background about serving hits without running the handler whose responses are cached. That raises a separate execution question. Here the narrower issue is the content delivered from shared storage. Even when skipping handler execution is legitimate, the stored body still has to be appropriate for every reader who can receive that entry.
Imagine a hypothetical account page whose response includes a person's address. Removing Set-Cookie would not remove the address. A rule matching the page can change the cache treatment without changing what the origin rendered. The example does not describe a discovered deployment vulnerability. It shows why cache eligibility and permission to share the resulting bytes require different evidence.
Write down what public means
A useful public-content contract identifies the selected response population. A path prefix may be part of that definition, but its name alone does not establish how every response under it is generated. A request can encounter an error page or a redirect instead of the intended asset. The review should account for the responses the rule actually selects, including exceptional paths.
The contract also needs to say which differences are legitimate. A public translation can differ by language while remaining public. A page containing a user's private details has a different restriction. The point is not to demand identical bytes from every request in the entire product. It is to establish that the audience allowed to receive each shared entry matches the content inside it.
Ownership makes this contract usable. The origin team knows what can enter the body; the edge team knows which responses its rule selects. If those teams are separate, neither should infer the other's knowledge from a header. A named owner should be able to explain both sides of the selection and resolve a disagreement before a broader override is introduced.
A static asset is a valid exception
The strongest case for an edge correction is a genuinely public static asset carrying an accidental session header. The vendor announcement explicitly discusses that situation. If the content is intended for all its recipients and the selection is narrow, changing its cache treatment at the edge can be a sensible correction. Waiting for an origin change is not inherently safer simply because it happens upstream.
The evidence must still attach to the selected asset population. An extension that looks static is a clue, not a content classification system. If the same route can return an authenticated error document, the selection deserves closer examination. This does not invalidate edge rules. It explains why the owner should know what the origin returns when the ordinary request does not succeed.
A narrow rule is also easier to maintain than a broad exception justified by one example. The public-content decision should survive a future change to the origin. If a team later adds personalization under the same path, someone needs to revisit the assumption that made sharing acceptable. Otherwise, an old performance correction can outlive the fact that justified it.
Review evidence from both ends
For a proposed rule, useful review material should describe the responses before and after the header adjustment, alongside the origin's content-generation conditions. The reviewer needs to understand why the body is shareable, not merely see that a cache obstacle disappeared. This article proposes that evidence; it does not claim to have inspected live headers or changed a cache configuration.
Operational measurements answer another question. A higher hit ratio may show that storage is being used more often. It cannot establish that the stored response belongs to the intended audience. A performance outcome and a content-safety argument should be assessed on their own evidence. One can improve while the other remains unresolved, which is why a single dashboard cannot settle both.
Keep responsibility with the content
In custom software development, an origin-to-edge handover should include the conditions under which a response may be shared. That gives the person maintaining the rule a meaningful boundary when the application changes. It also makes a reversal easier to reason about because the team knows which assumption has stopped holding.
Response-stage control is useful precisely because it can correct the origin's instructions at the point where they matter. Use that control with an explicit content contract. A stray header on a public asset can be fixed at the edge; private information remains private information after its headers have changed.