Cloudflare adds response-phase rules for cache decisions

Cloudflare introduced Cache Response Rules on July 23, adding a rule phase after an origin responds and before Cloudflare stores the object. The product post says the rules are available on all plans and can modify cache directives, manage cache tags, or strip selected response headers.

Response data can now change the final decision

Request-phase Cache Rules decide whether Cloudflare should look in cache, which key identifies the object, and initial caching behavior using information already present on the request. Cache Response Rules see status and headers that exist only after the origin answers. They can adjust Cache-Control, remove Set-Cookie, ETag, or Last-Modified, and add, remove, or replace cache tags.

The later phase has limits. It cannot change a cache key that was already selected, and it cannot make Cloudflare perform a cache lookup that the request phase skipped. Where the two phases conflict about whether or how to store the returned response, Cloudflare says the response rule wins.

Header rewrites require content-level proof

Stripping Set-Cookie from an accidentally personalized response could make private content shareable through cache. Before adding such a rule, teams should prove the matched path is invariant across users and authentication states. Tests need two distinct accounts, cache misses and hits, and inspection of browser-visible headers.

Removing validators also changes revalidation behavior. Operators should monitor origin requests, hit ratio, stale serving, and purge results after deployment instead of using a higher hit ratio as the only success measure. Cache tags need bounded cardinality and an ownership model so purges remain predictable.

The new phase removes the need for a Worker in several response-rewrite cases and gives CDN operators a precise correction point. That power makes rule scope and review especially important: the cache will faithfully amplify a mistaken declaration of shared content.