Cloudflare has launched Cache Response Rules, a rules engine that executes after an origin server delivers its response but before content is saved to Cloudflare's cache. Previously, Cache Rules worked only on request attributes, meaning they could only decide whether to retrieve content from cache before contacting the origin. The new feature adds a response phase that examines origin responses before they're cached, letting users adjust Cache-Control directives, handle cache tags, and remove headers like Set-Cookie, ETag, and Last-Modified without altering the origin application.
Cache Response Rules currently enable three actions: stripping headers that prevent caching, handling cache tags, and adjusting Cache-Control directives. Cache decisions now happen in two distinct phases—request-time rules determine whether and how to retrieve content from the cache before reaching the origin, while the new Cache Response Rules operate after the origin responds, permitting response headers to alter caching behavior before the content is saved. When a visitor requests /static/app.js and Cloudflare's cache doesn't contain it, the request goes to the origin, which returns the response. If that response includes a Set-Cookie header, the asset that should have been cached at every Cloudflare data center becomes uncacheable, multiplying across every visitor and every site with the same accidental header.
Alex Krivit, senior product manager at Cloudflare, and Anthony Turcios, former systems engineer at Cloudflare, write: "If you've ever been irked watching something that should easily sail out of cache get dragged back to the origin by a stray Set-Cookie or wrong Cache-Control, headers that are sometimes hard or impossible to strip or change on the origin itself, then Cache Response Rules is that fix, applied at exactly the right moment." The team clarifies that Cache Response Rules don't replace Cache Rules—Cache Rules decide whether, what, and how Cloudflare caches on the request, while Cache Response Rules get the final word on the how and whether once the origin's response is seen by Cloudflare in a phase that didn't exist before. Marcella dePunzio comments on LinkedIn that improving cache performance often comes down to optimizing response behavior rather than adding more infrastructure.
According to the documentation, the new rules enable finer control over cache behavior, improve cache hit rates, and simplify CDN migrations by letting teams modify caching policies at the edge without requiring code changes. Cache Response Rules execute after Cloudflare receives a response from the origin but before it's stored in the cache, solving the problem where cache hit ratios leak origin bandwidth, damage performance, and push infrastructure costs higher due to headers that prevent caching. Yuvdeep Singh, founder of Mission FinOps, notes that fixing origin mistakes at the edge without waiting on application changes is a significant win, though some practitioners expressed skepticism about forcing caching if engineers incorrectly classify dynamic content as cacheable. Cache Response Rules are available across all Cloudflare plans, giving teams greater control over caching policies at the edge to increase efficiency, reduce origin load, and simplify application management. The shift from request-only cache control to a two-phase system reflects a broader industry recognition that origin applications can't always be modified quickly, and edge processing needs to compensate for real-world header configurations that break caching assumptions.