Introducing Cache Response Rules (opens in new tab)
Cache Response Rules let Cloudflare modify an origin response after it arrives but before it is stored in cache. They address response-header problems—such as accidental `Set-Cookie`, restrictive `Cache-Control`, or problematic validators—that can unnecessarily reduce cacheability. This provides an origin-independent fix while preserving the distinction between request-time and response-time caching decisions. ## When Caching Decisions Are Made - CDN caches aim to serve content from the edge and contact the origin only on misses. - Origin response headers determine: - Whether content can be cached - How long it remains fresh - When it should be revalidated - Whether it should be cached at all - Common problems include: - `Set-Cookie` on static assets such as `/static/app.js`, making them uncacheable - `Cache-Control: no-cache` on content that is safe to cache at the CDN - Browser-oriented cache directives that are unsuitable for Cloudflare - Overly aggressive `ETag` values causing repeated revalidation - These issues often require coordination between separate origin and CDN teams, delaying simple fixes. ## Cache Response Rules - Run after the origin responds but before Cloudflare writes the response to cache. - Can: - Rewrite `Cache-Control` directives - Strip `Set-Cookie`, `ETag`, and `Last-Modified` - Manage cache tags for purging - Apply entirely within Cloudflare, without requiring origin code changes. - They solve problems that request-time rules cannot, because response headers are unavailable until after the origin request completes. ## The Missing Piece in Cloudflare’s Cache Controls - Earlier caching behavior was largely handled through Page Rules, which combined caching with unrelated features. - Cloudflare later introduced more focused controls, including: - Cache Rules - CDN-Cache-Control - Custom cache keys - Other cache-specific settings - Most existing controls operate during the request phase. - Before contacting the origin, Cloudflare can evaluate only request information such as the URL, headers, file extension, geography, and device type. - Previously, response-header problems required: - Changing the origin - Deploying a Worker to re-fetch and rewrite responses - Accepting a lower cache hit ratio ## Two Phases, Two Questions - **Cache Rules** run before the origin request and determine: - Whether the response is eligible for caching - What cache key identifies the object - How it should be cached, including TTL and stale-serving behavior - **Cache Response Rules** run after the origin response and determine whether caching behavior should be adjusted: - Remove headers that make content ineligible - Change origin cache directives - Set cache tags - When the two rule types conflict, the Cache Response Rule takes precedence. - Response rules cannot change the cache key, since that must already be established during the request phase. - They can make an otherwise eligible response non-cacheable with `no-store`, or make content eligible by removing `Set-Cookie`, but they cannot recover the latency of a request that was already excluded from caching at request time. Cache Response Rules complement rather than replace Cache Rules. Use request-phase rules for cache eligibility, keys, and general caching behavior; use response-phase rules to correct origin headers before they damage cacheability.