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.