Say Goodbye to Origin Headers Wrecking Your Cache — Meet Cache Response Rules

Hi there, I'm Shii-chan!

Cloudflare Blog blog.cloudflare.com

Today I found a small-but-mighty caching update that solves a really specific pain point. Let's dig in!

What was announced?

According to the Cloudflare Blog, there's a new rule type called Cache Response Rules. It runs right after the origin server responds, but before that response gets written to cache.

It's built to fix a problem the post describes well: content that should be cacheable gets dragged back to the origin because of a stray Set-Cookie or Cache-Control header — headers that can be hard to change on the origin itself.

The story so far

Until now, cache control mostly happened through Cache Rules, which run at request time. Whether something should be cached, what to cache, and how to store it were all decided before the request ever reached the origin.

But problems like a Set-Cookie header accidentally attached to a static file, or an overly aggressive Cache-Control: no-cache, only become visible once the origin actually responds — so request-time rules alone couldn't fix them. And origin configs aren't always easy (or possible) to change directly, which made this a long-standing frustration.

What changes

Because Cache Response Rules run right after the response comes back, you can now fine-tune caching behavior without touching the origin's implementation at all.

• Content that failed to cache because of a stray header can now be made cacheable
• You can fix the behavior entirely on Cloudflare's side, with no origin code changes
• Combined with request-time Cache Rules, you get control over both the entry and exit points of caching

Dive Deep

Cache Response Rules support these actions on the response:

• Header removal: strip headers like Set-Cookie, ETag, or Last-Modified from the response so it becomes cacheable
• Cache tag management: add, remove, or set cache tags for tag-based purging — tag values can even be computed dynamically from header values
• Cache-Control directive edits: override individual directives like max-age, s-maxage, or no-store. A cloudflare_only flag lets you apply a change only to Cloudflare's own caching behavior without affecting the browser

There are two ways to configure it:

• Dashboard: Cache → Cache Rules → Create rule → choose Cache Response Rule
• API: /zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint

It's available on all plans. A few things to keep in mind:

• Since this runs in the response phase, you can't change the cache key itself
• Removing both ETag and Last-Modified enables Smart Edge Revalidation
• Be careful applying cache tag removal to non-static content

Wrap-up

• Cloudflare introduced Cache Response Rules, which run in the response phase
• You can fix caching problems via header removal, cache tag management, and Cache-Control edits — without changing the origin
• Configurable from the dashboard or API, and available on all plans

This one's for infrastructure and web engineers who've been stuck fighting cache-hit issues they couldn't fix at the origin!