Targeted HTTP Cache-Control: How RFC 9213 and CDN-Cache-Control Manage Edge Freshness

Modern web architectures routinely pass HTTP responses through multiple caching tiers, including origin caches, content delivery networks (CDNs), intermediate shared proxies, and client web browsers. Historically, publishers had to rely on standard HTTP Cache-Control response headers defined in RFC 9111. While directives like s-maxage distinguish shared caches from private browser caches, standard HTTP directives cannot selectively target a specific CDN network or differentiate between multiple CDN intermediaries along the request path.

RFC 9213: Targeted HTTP Cache Control defines a standardized framework for targeting cache directives at specific intermediary classes using dedicated response header fields, prominently establishing the permanent IANA-registered header CDN-Cache-Control. In parallel, providers such as Cloudflare implement vendor-specific variants like Cloudflare-CDN-Cache-Control, as detailed in the Cloudflare CDN-Cache-Control documentation. This explainer covers how targeted header precedence works, how edge proxies handle downstream forwarding, and how to structure origin headers safely.

The Problem RFC 9213 Solves

According to Section 1 of RFC 9213, website operators often maintain direct relationships and programmatic invalidation capabilities with their CDNs. Because an origin can actively purge stale or updated content from its CDN edge via API or dashboard, the operator may prefer assigning a longer, more aggressive freshness lifetime to the CDN. Conversely, browsers and unmanaged third-party shared caches lack instant purge mechanisms, requiring conservative freshness lifetimes to prevent users from seeing outdated content.

Before RFC 9213, achieving this required ad-hoc proprietary headers or custom routing logic with low cross-platform interoperability. RFC 9213 introduces a structured way for origin servers to emit cache directives intended exclusively for CDNs, leaving downstream browsers and generic caches governed by standard Cache-Control.

Target Lists and Header Precedence Hierarchy

Under RFC 9213 Section 2.2, any cache implementing the specification maintains an ordered target list of targeted field names prioritized from most specific to least specific. When processing a response, the cache scans for the first member of its target list that is present, valid, and non-empty. If none matches, it falls back to standard HTTP caching mechanisms.

When interacting with Cloudflare’s edge implementation, precedence is determined by the following documented rules:

1. Cloudflare Cache Response Rules: If a dashboard Cache Response Rule sets directives using the set_cache_control action, those directives override any origin-set Cloudflare-CDN-Cache-Control or CDN-Cache-Control headers.
2. Edge Cache TTL Rules: A configured Edge Cache TTL cache rule overrides the time an asset is cached on Cloudflare edge data centers, taking precedence over origin targeted headers.
3. Cloudflare-CDN-Cache-Control: When evaluating origin headers without overriding edge rules, Cloudflare prioritizes Cloudflare-CDN-Cache-Control over CDN-Cache-Control because it represents the most specific targeted header for its network.
4. CDN-Cache-Control: Evaluated if Cloudflare-CDN-Cache-Control is not returned by the origin.
5. Surrogate-Control: As documented by Cloudflare, surrogates will not honor Cache-Control headers; if Surrogate-Control is present, Cloudflare ignores origin Cache-Control directives even if Surrogate-Control carries no directives.
6. Standard Cache-Control & General Defaults: If no targeted headers are present, Cloudflare uses standard Cache-Control or falls back to its general default cache values.

Core Directives and Syntax Rules

RFC 9213 mandates that caches implementing targeted fields must support standard HTTP caching directive semantics, including:

• max-age: Specifies freshness lifetime in seconds (represented as an integer).
• no-store: Prohibits storing the response (boolean true).
• no-cache: Requires revalidation before reuse (boolean true or a comma-delimited field list string).
• must-revalidate: Prevents serving stale responses without origin revalidation.
• private: Restricts storage to private caches.

The precedence within a targeted header mirrors standard Cache-Control: directives like no-store and no-cache render max-age inoperative, and unrecognized extensions are ignored. Furthermore, implementations must not generate or consume malformed values (such as decimal numbers for max-age). If a targeted header is empty or encounters a parsing error, RFC 9213 requires the cache to ignore that field completely and fall back to subsequent mechanisms.

Edge vs. Downstream Forwarding Behavior

A critical architectural consideration in multi-tier caching is whether an edge proxy strips or forwards targeted headers downstream toward clients:

RFC 9213 Section 2.2 adds that targeted fields not present on an intermediate cache’s target list MUST NOT alter that cache’s behavior and MUST be passed through untouched.

Concrete Origin Header Patterns

Pattern 1: Long Edge TTL with Short Browser Caching

To keep an asset in Cloudflare’s edge for 6.7 hours (24,400 seconds), in intermediate CDNs for 5 hours (18,000 seconds), in shared proxies for 23.3 hours (84,000 seconds), and in client browsers for 4 hours (14,400 seconds), configure the origin response headers as demonstrated in Cloudflare’s documentation:

Cache-Control: max-age=14400, s-maxage=84000
Cloudflare-CDN-Cache-Control: max-age=24400
CDN-Cache-Control: max-age=18000

Pattern 2: Caching Exclusively on CDNs While Forbidding Browser Storage

RFC 9213 Section 3.1 demonstrates how an origin can keep content cached across CDN nodes while forbidding downstream browsers and shared caches from writing to disk:

Cache-Control: no-store
CDN-Cache-Control: max-age=600

Under this configuration, any cache whose target list includes CDN-Cache-Control treats the response as fresh for 600 seconds. All other intermediaries and browsers inspect Cache-Control: no-store and do not store the response.

Pattern 3: Differentiated Stale-If-Error Handling

Cloudflare supports setting error fallback intervals across tiers using the stale-if-error extension directive:

Cache-Control: stale-if-error=400
Cloudflare-CDN-Cache-Control: stale-if-error=60
CDN-Cache-Control: stale-if-error=200

If the origin returns a 5xx error, Cloudflare serves stale content for up to 60 seconds. Downstream CDNs inspecting CDN-Cache-Control serve stale content for up to 200 seconds, while client caches inspecting Cache-Control may serve stale content for up to 400 seconds if they implement that directive.

Freshness Interactions and Security Considerations

Section 2.3 of RFC 9213 warns about the HTTP end-to-end freshness model defined in RFC 9111. When an upstream CDN has a significantly longer freshness lifetime than downstream caches, it can serve a response accompanied by an incremented Age header that causes downstream caches to view the response as immediately stale:

Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600

In this documented scenario, the CDN considers the object fresh for an hour and serves it after 30 minutes (Age: 1800). Downstream caches reading Cache-Control: max-age=600 evaluate the Age (1800 seconds) as exceeding max-age (600 seconds), regarding the object as stale upon arrival and triggering immediate revalidations.

Additionally, Section 5 notes that carrying disparate caching policies across multiple header fields increases configuration complexity. If an operator inadvertently permits caching in a targeted header on an endpoint carrying sensitive personalized data while relying on a blanket Cache-Control: private or no-store, intermediaries honoring the targeted header may store and reuse sensitive responses across multiple users.

Research Method and Documented Limitations

This technical guide was prepared solely from public standards and official vendor documentation: IETF RFC 9213 (June 2022) and Cloudflare’s official CDN-Cache-Control product guide (retrieved September 2026). No third-party competitor pages or synthetic performance benchmarks were utilized. Configuration rules reflect Cloudflare edge mechanics and general RFC 9213 specifications; behaviors may differ on other CDN providers whose target lists, stripping rules, and extension directives follow distinct internal priority sequences.