Cloudflare launches Cache Response Rules to fix origin headers that break CDN caching

Cloudflare said it is introducing Cache Response Rules, a new rule type that runs after an origin server replies but before Cloudflare caches the content. The company said the feature targets cases where response headers such as Set-Cookie or Cache-Control make assets uncacheable at the edge even when the body itself is safe to store. According to the Cloudflare Blog, existing Cache Rules operate in the request phase and decide whether to look up cache, under what key, and with what TTL settings before talking to the origin. Cache Response Rules run in the response phase and can strip headers, rewrite Cache-Control directives, and manage cache tags once the origin response is visible. When a cache rule and a cache response rule conflict, the blog said the cache response rule wins. The post said three actions are available today: strip headers such as Set-Cookie, ETag, or Last-Modified before cache evaluation; set, add, or remove cache tags used for purge-by-tag, including tags derived from response headers such as Surrogate-Keys; and modify Cache-Control directives including max-age, s-maxage, stale-if-error, stale-while-revalidate, private, no-cache, no-store, and related flags. Directives can be marked cloudflare_only so they affect Cloudflare caching without changing the Cache-Control value sent to the browser. Cloudflare said prior workarounds were changing the origin, writing a Worker that re-fetches and rewrites the response, or accepting a worse hit ratio. The company said Cache Response Rules apply the fix at the edge without origin code changes. The blog noted response-phase rules cannot change the cache key, which is fixed in the request phase, and cannot make a previously ineligible request cacheable after the origin fetch has already been paid for.