Skip to content

SYSTEM Cited by 4 sources

Cloudflare Cache

Cloudflare Cache is the HTTP cache layer embedded in every Cloudflare POP (point-of-presence) that sits between client requests and customer origins. It is the primary substrate on which Cloudflare delivers its CDN, DDoS, and compression value, and the cache layer where dictionary-variant storage lives for Cloudflare Shared Dictionaries.

Minimal stub page — deeper treatment pending a dedicated post on the cache's internals.

Cache-key mechanics (scope: shared-dictionaries launch)

For systems/cloudflare-shared-dictionaries Phase 1 passthrough, the cache key is extended to vary on both:

  • Accept-Encoding — whether the client supports gzip / br / zstd / dcb (delta-Brotli) / dcz (delta-Zstandard).
  • Available-Dictionary — which dictionary hash (if any) the client has cached.

Consequence: mid-deploy, the edge can hold multiple cache variants of the same URL — gzip, Brotli, Zstd, dcz-against-v1, dcz-against-v2, raw — each served to the client whose cached dictionary + Accept-Encoding match. Storage pressure grows with the dictionary-variant cardinality; named cache-variant explosion.

Vary support in Cache Rules (2026-09-22)

Cloudflare shipped Vary support in Cache Rules on every plan, splitting content-negotiation handling into two decisions: the origin names the request headers that may affect a response via Vary (RFC 9110); the customer's Cache Rule decides, per named header, how Cloudflare treats the value. This is the direct control for cache-variant explosion — the failure mode where naive per-byte variant keying fragments identical responses into permanently-cold entries.

Three per-header actions (rule default action applies to un-configured named headers):

  • normalize (recommended default) — canonicalize the request header before variant selection so equivalent requests share one entry. For Accept / Accept-Language / Accept-Encoding: lowercase, sort by quality value (highest first, alphabetical tie-break, so client ordering doesn't affect the key), strip parameters from nonzero-q entries, fold regional tags (en-US → en) unless the full tag is configured, and filter to configured media-types/languages. Other headers: trim optional whitespace, combine repeated lines in original order. Normalized Accept / Accept-Language are forwarded to the origin (and normalized Accept-Encoding when Respect Strong ETags is enabled) to keep origin selection aligned with cache matching.
  • passthrough — key on the header's raw bytes (casing, whitespace, order, duplicates preserved). For controlled value sets where the exact value changes the response. Incidental differences (X-View: compact,full vs Compact,full vs compact, full) each mint a separate key.
  • bypass — don't store the response when the origin names that header in Vary. For personalized / high-cardinality / unexpected headers (Cookie, User-Agent). Existing entries are not purged automatically.

Vary: * always bypasses cache (any request aspect, even client IP, may matter). Lookup is direct: Cloudflare reads the stored Vary field names, applies the Cache Rule to those headers in the new request, and looks up the matching variant by computed key — it does not scan every stored variant. The origin must return Vary consistently across all cacheable responses, including errors/fallbacks, or a response can be cached without its isolating variance.

Configured via the dashboard, the Rulesets API (http_request_cache_settings phase, action_parameters.vary with default + per-header action / media_types / languages), and Terraform. Distinct from a custom cache key, which adds a dimension to every response under the rule whether the origin used it or not; Vary is response-driven. Changing a Vary config does not auto-purge — requests refill under new keys while old entries linger. (Source: sources/2026-09-22-cloudflare-we-just-shipped-support-for-the-ugliest-part-of-http-vary)

Compression at rest (Cache Transcoding, 2026-09-01)

Separate from the dictionary-variant work above, Cloudflare prototyped Cache Transcoding — compressing eligible uncompressed cache text with zstd at rest, inside the Pingora proxy, independent of the origin's content encoding. The compressed form is kept across Tiered Cache and decoded only on the client-facing hop. On the prototype's test corpus eligible assets shrank ~2.8×, raising cache density (more objects retained per server, less eviction of useful content) and reducing cross-data-center backbone traffic. Distinct from Shared Dictionaries: that transports client-facing delta encodings (dcb/dcz) between origin and browser; Cache Transcoding is an internal at-rest compression the client never sees. (Source: sources/2026-09-01-cloudflare-how-we-could-save-petabytes-of-cache-storage-with-zstandard)

See also

Seen in

Last updated · 766 distilled / 2,225 read