Cloudflare adds response-phase cache control rules

Cloudflare has rolled out a new rule type called Cache Response Rules, designed to address caching inefficiencies caused by origin server misconfigurations. These rules execute after an origin responds but before Cloudflare caches the content, enabling operators to override problematic headers without modifying the origin itself.

The feature aims to resolve a persistent challenge in CDN management: origin servers often include headers like Set-Cookie or incorrect Cache-Control directives that prevent otherwise cacheable assets from being stored. These issues frequently arise when different teams manage the origin and CDN, making header adjustments a slow and complex process. Cache Response Rules provide a workaround by allowing changes to be made at the CDN level, bypassing the need for origin modifications.

How the rules work

Cache Response Rules operate in a distinct phase of the request-response cycle. Traditional Cache Rules, which run during the request phase, determine whether and how Cloudflare should cache a response based on request parameters like URL, headers, or geography. However, they cannot account for response-specific details, such as Cache-Control directives or ETag headers, which are only available after the origin replies.

Cache Response Rules fill this gap by executing after the origin responds but before the content is written to Cloudflare’s cache. This allows operators to rewrite Cache-Control directives, strip problematic headers like Set-Cookie or ETag, or manage cache tags. The rules do not replace Cache Rules but complement them, providing a final layer of control over caching behavior.

Key capabilities

The new rules support three primary actions:

1. Stripping headers: Operators can remove headers like Set-Cookie, ETag, or Last-Modified from origin responses. This is particularly useful for static assets that inadvertently include session cookies, making them uncacheable. The rules can also strip headers from dynamic responses, even if the content is not cached.

2. Managing cache tags: The set_cache_tags action allows operators to add, remove, or set cache tags for purging content by tag. This is valuable during CDN migrations, where origin servers may use vendor-specific tag formats. For example, Cloudflare can translate surrogate keys from another CDN into its own Cache-Tag format.

3. Modifying Cache-Control directives: The set_cache_control action enables operators to set or remove individual directives, such as max-age, s-maxage, or no-cache. A key feature is the cloudflare_only flag, which applies changes only to Cloudflare’s caching behavior while leaving the downstream Cache-Control header intact for browsers.

Practical applications

Cache Response Rules address several common scenarios:

• Static assets with session cookies: Many origin frameworks attach Set-Cookie headers to all responses, including static assets like JavaScript or CSS files. Stripping these headers for specific file extensions (e.g., .js, .css) makes the assets cacheable without origin changes.

• Decoupling cache lifetimes: Operators can set longer cache durations for Cloudflare while keeping shorter durations for browsers. For example, a static asset might be cached for 30 days at Cloudflare but only 1 day in the browser, using the immutable directive to prevent unnecessary revalidation.

• Overriding framework defaults: Some frameworks attach no-cache to all responses by default. Cache Response Rules can remove this directive for known-static paths (e.g., /static/) and impose a custom TTL for Cloudflare.

• CDN migrations: During migrations, origin servers may emit cache tags in a format incompatible with Cloudflare. The rules can translate these tags into Cloudflare’s format, ensuring purge-by-tag functionality works immediately.

Limitations and considerations

While Cache Response Rules provide granular control, they have limitations. They cannot change the cache key or make a previously ineligible request cacheable, as these decisions are made during the request phase. Additionally, stripping headers like ETag and Last-Modified may affect revalidation behavior, requiring operators to weigh the trade-offs.

The rules are available on all Cloudflare plans and can be configured via the dashboard or API. Operators can access them under the Cache Rules section in the Cloudflare dashboard or through the /zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint API endpoint.