推出缓存响应规则

详细说明

Blog Application Services Cache Cache Rules +3 Show 3 more tags

6 Tags Show 6 tags

CDN Optimization Product News

Application Services Cache Cache Rules CDN Optimization Product News

July 23, 2026

• Selected Tags
• Application Services Cache Cache Rules CDN Optimization Product News
• All tags
• Matching tags
• No tags found
• 1.1.1.1
• 2FA
• Abuse
• Access
• Access Control Lists (ACLs)
• Accessibility
• Account Takeover
• Acquisitions
• Addressing
• Advanced Certificate Manager
• Advanced DDoS
• Advertising
• Aegis
• Africa
• Afroflare
• Agent Readiness
• Agents
• Agents Week
• AI
• AI Bots
• AI Gateway
• AI Search
• AI-SPM
• AI WAF
• AI Week
• Alertmanager
• Always Online
• AMD
• AMP
• Analytics
• Anonymous
• Anti Malware
• Anycast
• API
• API Gateway
• API Security
• API Shield
• APJC
• Apple
• Application Security
• Application Services
• Area 1 Security
• Argo Smart Routing
• ASCII
• Asia
• Athenian Project
• Atlassian
• Attacks
• Audit Logs
• Austin
• Australia
• Authentication
• Authy
• Automatic HTTPS
• Automatic Platform Optimization
• Automation
• AutoMinify
• Auto Rag
• Awards
• AWS
• Baidu
• Bandwidth Alliance
• Bandwidth Costs
• Best Practices
• Beta
• Better Internet
• BGP
• Birthday Week
• Blackbird
• Black Friday
• Bot Fight Mode
• Bot Management
• Botnet
• Bots
• BPF
• Brand
• Brand Protection
• Brazil
• Browser Insights
• Browser Rendering
• Browser Run
• Bug Bounty
• Bugs
• BYOIP
• Cache
• Cache Purge
• Cache Reserve
• Cache Rules
• California
• Canada
• Cap'n Proto
• CAPTCHA
• Careers
• CASB
• Categories
• CDN
• CDNJS
• Certificate Authority
• Certificate Pinning
• Certificate Transparency
• Certification
• CFSSL
• Challenge Page
• ChatGPT
• China
• China Network
• Christmas
• Chrome
• CIO Week
• CISA
• Claire
• CLI
• ClickHouse
• Clientless
• Clientless Web Isolation
• Cloud Connector
• Cloud Email Security
• Cloudflare Access
• Cloudflare Apps
• Cloudflare Area 1
• Cloudflare Calls
• Cloudflare Email Service
• Cloudflare for Campaigns
• Cloudflare for SaaS
• Cloudflare for Startups
• Cloudflare Gateway
• Cloudflare History
• Cloudflare Images
• Cloudflare Media Platform
• Cloudflare Meetups
• Cloudflare Network
• Cloudflare One
• Cloudflare One Client
• Cloudflare One User Risk Score
• Cloudflare One Week
• Cloudflare Pages
• Cloudflare Polish
• Cloudflare Queues
• Cloudflare Realtime
• Cloudflare Stream
• Cloudflare Tunnel
• Cloudflare TV
• Cloudflare Workers
• Cloudflare Workers KV
• Cloudflare Workers KV (ES)
• Cloudflare Workers (PT)
• Cloudflare Zero Trust
• Cloudforce One
• Cloudy
• Code Orange
• Coinbase
• Colombia
• Community
• Compliance
• Compression
• Config Rules
• Configuration Management
• Congestion Control
• Connectivity
• Connectivity Cloud
• Consumer Services
• Containers
• Content Independence Day
• Content Scanning
• Context
• Core
• COVID-19
• Crawler Hints
• CrowdStrike
• Cryptography
• Crypto Week
• CSAM Reporting
• Customers
• Customer Success
• Customer Zero
• CVE
• CVE-2023-50387
• Cyber Readiness
• Cybersecurity
• D1
• Dashboard
• Data
• Database
• Data Catalog
• Data Center
• Data Localization
• Data Localization Suite
• Data Loss
• Data Loss Prevention
• Data Platform
• Data Privacy Day
• Data Protection
• Data Sovereignty
• Data Transfer Bucket
• DDoS
• DDoS Alerts
• DDoS Reports
• Debugging
• Deep Dive
• Descaler
• Design
• Deskope
• Developer Documentation
• Developer Platform
• Developers
• Developer Spotlight
• Developers Storage
• Developer Week
• Device Security
• DevOps
• DEX
• Digital Experience Monitoring
• Digital Forensics
• Disrupt
• Distributed
• Distributed Systems
• Distributed Web
• Diversity
• DLP
• DMARC
• DNS
• DNS Filtering
• DNS Flood
• DNSSEC
• DNS Security
• Dogfooding
• DoH
• Domain Rankings
• Domain Scoped Roles
• dosd
• Drupal
• Due Process
• Durable Execution
• Durable Objects
• Early Hints
• Earth Day
• eBPF
• EC2
• eCommerce
• Edge
• Edge Computing
• Edge Database
• Edge Rules
• Education
• Egress
• Elastic
• Elections
• Election Security
• Elliptic Curves
• Email
• Email Routing
• Email Security
• Email Workers
• EmDash
• Emissions
• Employee Resource Groups
• Encrypted SNI
• Encryption
• Engineering
• Enterprise
• Entropy
• EPYC
• Ethereum
• Europe
• European Union
• Events
• Exploit
• Facebook
• Fancy Bear
• Fast Fonts
• FCC
• Feature Flags
• FedRAMP
• FedRAMP High
• FedRAMP Moderate
• Firefox
• Firewall
• Firmware
• Florida
• Football
• Formal Methods
• Forrester
• Fortran
• Foundation DNS
• Founders' Letter
• France
• Fraud
• Free
• Freedom of Speech
• Front End
• Full Stack
• Full Stack Week
• Fun
• Gartner
• Gatebot
• GA Week
• GDPR
• General Availability
• Generative AI
• Gen X
• Geo Key Manager
• Germany
• GitHub
• Go
• Google
• Google Analytics
• Google Cloud
• Google Workspace
• Government Innovation
• Grace Hopper
• Grafana
• GraphQL
• Green
• Grinch
• Growth
• gRPC
• Guest Post
• Hackathon
• Halloween
• Hardware
• HashiCorp
• Hertzbleed
• Heuristics
• History
• Holidays
• Holocaust
• Hong Kong
• Hosting Con
• Hostnames
• HTTP2
• HTTP3
• HTTPS
• Human Rights
• Hurricane
• Hybrid Cloud
• Hyperdrive
• IBM
• ICANN
• iCloud Private Relay
• Identity
• IETF
• IL4
• Image Optimization
• Image Recognition
• Image Resizing
• Image Storage
• Impact
• Impact Week
• I'm Under Attack Mode
• Incident Report
• Incident Response
• India
• Indicators of Compromise
• Indonesian
• Infrastructure
• Infrastructure as Code
• Insights
• Intel
• Interconnection
• Internal DNS
• Internet Performance
• Internet Quality
• Internet Regulation
• Internet Shutdown
• Internet Summit
• Internet Traffic
• Internet Trends
• Internship Experience
• Intrusion Detection
• Investors
• IoCs
• iOS
• IoT
• IPFS
• IPsec
• IPv4
• IPv6
• IRAP
• Israel
• Italy
• IWD
• JAMstack
• Japan
• JavaScript
• Jengo
• Jengo Policy
• Joomla
• Judeoflare
• Kafka
• Kernel
• Keyless SSL
• KeyTrap
• Key Value
• Killnet
• Korea
• Kubernetes
• LangChain
• Latency
• Latin America
• Latinflare
• LavaRand
• Lazarus group
• Leaked Credential Checks
• Legal
• Legal Patents Sable
• LGBTQIA+
• Life at Cloudflare
• Linux
• Lisbon
• Live Streaming
• Llama
• LLM
• Load Balancing
• Localization
• Log4J
• Log4Shell
• Logging
• Log Push
• Logs
• LUA
• Machine Learning
• Magecart
• Magic Firewall
• Magic Network Monitoring
• Magic Transit
• Magic WAN
• Magic WAN Connector
• Malicious JavaScript
• Malware
• Managed Components
• Managed Rules
• March of Cloudflare
• MASQUE
• MCP
• Meerkat
• MeetUp
• Meris
• Message Protocol
• Mexico
• Micro-frontends
• Microsoft
• Microsoft 365
• Microsoft Azure
• Middle East
• Migration Hub
• Milestones
• Miniflare
• Mirage
• Mirai
• Mitel
• Mitigation
• Mixed Content Errors
• MLops
• Mobile
• Mobile SDK
• Model Context Protocol
• Moldova
• Monitoring
• Multi-Cloud
• Multi-User
• MySQL
• NaaS
• Net Neutrality
• Network
• Networking
• Network Interconnect
• Network Performance Update
• Network Protection
• Network Services
• New Year
• NGINX
• Ninjas
• NIST
• Node.js
• North America
• Notebooks
• Notifications
• NSEC3
• OAuth
• Observability
• Oceania
• OCSP
• Offices
• Okta
• Olympics
• Onboarding
• OpenAI
• Open API
• OpenBMC
• OpenDNS
• Open Source
• OpenSSL
• OpenTelemetry
• Optimization
• Origin Rules
• Outage
• Oxy
• Pacific Northwest
• Page Rules
• Page Shield
• Parallels
• Partners
• Partnership
• Password-reuse
• Passwords
• Passwords (PT)
• Patents
• PAYGO
• Payments
• Pay Per Crawl
• PCI Certified
• Peering
• Performance
• Phishing
• php
• Phython
• Pingora
• Pipelines
• PlanetScale
• Plans
• Platform Engineering
• Platform Week
• Plesk
• Policy & Legal
• Politics
• Portugal
• Postgres
• Post Mortem
• Post-Quantum
• Precursor
• Prepared Statements
• Prisma
• Privacy
• Privacy Pass
• Privacy Week
• Private IP
• Private Network
• Product Design
• Product News
• Programming
• Programming (PT)
• Project Fair Shot
• Project Galileo
• Project Honey Pot
• Project Pangea
• Project Safekeeping
• Project Turpentine
• Prometheus
• Protocols
• Proudflare
• Proxying
• Public Sector
• Python
• Queues
• QUIC
• QUICHE
• Quicksilver
• R2
• R2 Super Slurper
• Radar
• Radar Alerts
• Radar API
• Radar Maps
• Railgun
• Randomness
• Ransom Attacks
• Rapid Reset
• Raspberry Pi
• Rate Limiting
• RC4
• RDDoS
• React
• Reading List
• Real-time
• Recruiting
• Regional Services
• Registrar
• Reliability
• Remote Browser Isolation
• Remote Desktop Protocol
• Remote Work
• Replication
• Research
• Resolver
• Restreaming
• Retreat
• Reverse Engineering
• REvil
• Risk Management
• Road to Zero Trust
• Rocket Loader
• RocksDB
• Routing
• Routing Security
• RPKI
• RRDNS
• RSA
• Russia
• Rust
• Rust Workers
• SaaS
• SAAS Security
• Sable
• Salt
• Sampling
• Sandbox
• SASE
• Save The Web
• SDK
• Search Engine
• Secrets Store
• Secure Web Gateway
• Security
• Security Analytics
• Security Center
• Security Posture
• Security Posture Management
• Security Service Edge
• security.txt
• Security Week
• SEO
• Serverless
• Serverless AI
• Serverless (PT)
• Serverless Week
• Server Push
• Servers
• SIEM
• Signed Exchanges (SXG)
• SIM
• Singapore
• Single Sign On (SSO)
• Smart Placement
• Smart Shield
• Snippets
• SOC as a Service
• South Africa
• South America
• Spain
• spdy
• Spectrum
• Speed
• Speed Brain
• Speed & Reliability
• Speed Week
• Spoofing
• Sports
• SQL
• SRE
• SSE
• SSH
• SSL
• Standards
• Startup Enterprise Plan
• Statistics
• StopTheHacker
• Storage
• Sumo Logic
• Super Bowl
• Supercloud
• Supply Chain Attacks
• Support
• Sustainability
• SWAG
• SWG
• Swift
• Switzerland
• SXSW
• SYN
• SYN Flood
• Syria
• TCP
• Team
• Teams Dashboard
• TechCrunch
• Technical Writing
• Tech Talks
• Terraform
• Testimonials
• Testing
• Texas
• Thanksgiving
• The Serverlist Newsletter
• Threat Data
• Threat Feeds
• Threat Intelligence
• Threat Operations
• Threats
• Tiered Cache
• TikTok
• TLS
• TLS 1.3
• Tools
• Tor
• Tracing
• Traffic
• Transform Rules
• Transparency
• Trends
• Trust & Safety
• TTFB
• TTL
• TURN
• TURN Server
• Turnstile
• TypeScript
• UDP
• Ukraine
• United Kingdom
• Universal SSL
• URL Scanner
• USA
• User Research
• VDI
• Vectorize
• Vetflare
• Video
• Visibility
• Vite
• VoIP
• VPC
• VPN
• Vulnerabilities
• WAF
• WAF Attack Score
• WAF Rules
• Waiting Room
• WARP
• WARP Connector
• WASM
• Web3
• Web Application Firewall
• WebAssembly
• Web Asset Discovery
• Webinars
• WebP
• WebRTC
• WebSockets
• Wildebeest
• Womenflare
• WordPress
• Workers AI
• Workers Launchpad
• Workers Logs
• Workers Observability
• Workers Sites
• Workers Unbound
• Workers VPC
• Workflows
• World IPv6 Day
• Wrangler
• x402
• Year in Review
• Z3
• Zaraz
• Zero Day Threats
• Zero Trust
• Zero Trust Week
• Zone Versioning

Introducing Cache Response Rules

Alex Krivit and Anthony Turcios

12 minute read

COPY URL

Today we’re excited to announce Cache Response Rules. These are a new rule type that runs after an origin server replies but before Cloudflare caches the content.

If you've ever been irked watching something that should easily sail out of cache get dragged back to the origin by a stray Set-Cookie or wrong Cache-Control , headers that are sometimes hard or impossible to strip or change on the origin itself, then Cache Response Rules is that fix, applied at exactly the right moment.

When and how caching decisions are made

A CDN cache and an origin server work as a pair. Their goal is to answer from the cache whenever possible and only go back to the origin when the edge can’t respond. Every point of cache hit ratio comes from getting that division of labor right. Check the cache when we shouldn't, and we waste a lookup that was always going to miss. Check it too rarely, the origin serves traffic the edge should have absorbed, and the performance win evaporates.

Importantly, the origin guides the cache. When it returns a cacheable asset, its response headers tell Cloudflare how long it’s OK to serve it, when and how to revalidate, and even whether to cache it at all. The cache is only ever as efficient as the origin allows. If the origin gets it wrong, cache becomes decoration while the origin infrastructure costs skyrocket.

Most cache eligibility problems are not decided at request time. They manifest after the origin replies.

A visitor asks for /static/app.js . Cloudflare checks cache, it misses, and forwards the request to the origin. The origin returns the file. Somewhere in those response headers, quietly, is a Set-Cookie header. The asset that should have been cached at every Cloudflare data center is now uncacheable. Multiply that by every visitor, on every site, with the same accidental header, and you have a cache hit ratio that is leaking origin bandwidth, ruining performance, and driving infrastructure costs higher.

There is a long list of variations of this same problem. The origin sends Cache-Control: no-cache on assets that are perfectly safe to cache on the CDN. The origin sends correct directives, but they're meant for the browser, not for Cloudflare. Or the origin attaches an ETag (an identifier for a specific version of a resource) that's overly aggressive and causes revalidation thrash on every conditional request. Often, especially in large teams, those managing the origin’s responses and the group that manages the CDN are different. This makes changing a one-line header a weeks-long negotiation.

None of these problems can be solved at request time. By the time Cloudflare sees the Set-Cookie on /app.js , the request phase is over. The response is already in flight.

So we put a fix in the right place.

Cache Response Rules run after the origin’s response arrives at Cloudflare, but before it gets written to cache. With them, you can rewrite Cache-Control directives, manage cache-tags, and strip headers like Set-Cookie , ETag , and Last-Modified from the origin response before Cloudflare's cache ever sees them. The fix lives entirely on Cloudflare. No origin code changes required.

The missing piece

If you've used Cloudflare for any length of time, you've watched the cache control surface area evolve. A few years ago, most of this lived inside Page Rules , which operated as a single, albeit overloaded, primitive that mixed caching with redirects, security, and a dozen other behaviors, all evaluated on requests. We later split these rules apart so that only relevant behavior changes would be evaluated against requests, reducing unnecessary latency and allowing for complex rule stacking between behaviors. Cache Rules became a dedicated, expressive rule type for caching decisions, joined by CDN-Cache-Control , Origin Cache Control , custom cache keys , and other controls that give you precise ways to tell Cloudflare what's safe to cache, for how long, and under what conditions.

Many of these controls share a common trait: they operate on the request .

While maybe unintuitive, this makes sense. The most important caching decisions Cloudflare has to make are should we look this up in cache, and under what key? This question has to be answered before Cloudflare talks to the origin. If the answer is "no" when it should have been "yes," the request has already paid for the origin round trip and there's nothing the response can do to give it back that latency. Request-time rules answer that question using the only information available at that moment: the URL, the requested file’s extension, the request headers, geography, device type, and so on. Using these request parameters and the rules set to change these request parameters, we determine if something is likely in cache and look there before talking with the origin.

But some cache decisions cannot be made on the request. The origin's Cache-Control directives (cache-control: max-age=3600) are part of the response Cloudflare receives from the origin. The status code, the ETag, the Last-Modified timestamp, Set-Cookie, and the cache-tag format the origin chooses are all things in the response that the origin passes to the cache. None of it is available when request-time rules run.

Responses from the origin are the source of truth, so if something needed to be changed on Cloudflare that wasn’t available at request time, that previously left you with three workarounds:

Each of those costs engineering time, adds latency, or burns money. Cache Response Rules give you a fourth option: a ruleset where you can modify the origin's response before it hits Cloudflare's cache.

• Change the origin.
• Write a Worker that re-fetches and rewrites the response.
• Live with a worse hit ratio.

Two phases, two questions

The cleanest way to think about the difference between Cache Rules and the new Cache Response Rules is as two phases, each answering its own question.

The response phase can't do everything the request phase can. It can't change the what, as the key is already fixed. Though it can change whether and how Cloudflare caches, for example, a response rule can set no-store to make a cacheable object non-cacheable or strip a Set-Cookie to make non-cacheable content eligible for cache. However, Cache Response Rules can't make a previously ineligible request cacheable by the response phase, because it’s too late.

So Cache Response Rules don't replace Cache Rules. Cache Rules decide whether , what , and how we cache on the request. Cache Response Rules get the final word on the how and whether , once the origin's response is seen by Cloudflare in a phase that didn't exist before.

• Cache Rules run in the request phase, before Cloudflare talks to the origin server. They answer: given this request, should Cloudflare cache the response, and under what cache key? That’s three decisions that can be made at request time with cache rules: whether to cache (eligible vs. bypass), what the object is (the cache key and how to identify the stored object in the future), and how to cache (edge TTL, browser TTL, serve-stale, etc). All of these questions must be settled before the origin fetch, using only what’s in the request.
• Cache Response Rules run in the response phase, after the origin replies but before the response is written to Cloudflare's cache. Cache Response Rules answer: now that the origin has responded, should we adjust how we cache it? Cache Response Rules can rewrite the how from the request by stripping headers that would make a response ineligible for cache, changing origin cache-control directives that tell Cloudflare whether and how to cache , or setting cache tags for purging content. When a cache rule and cache response rule are in conflict with each other, the cache response rule wins.

What you can do

Cache Response Rules support three actions today.

The set_cache_settings action removes things like Set-Cookie, ETag , or Last-Modified from the origin response before Cloudflare evaluates it for caching:

"action_parameters": {

"strip_etags": true,

"strip_set_cookie": true,

"strip_last_modified": true

}

This is the fix for the Set-Cookie-on-a-static-asset problem. Origin frameworks frequently attach session cookies to every response (for load balancing or other purposes), including responses for assets that users don't want to be associated with a session. Stripping Set-Cookie in the response phase makes those assets cacheable again without asking the origin, load balancer, or anything else upstream to change anything.

Cache Response Rules also run on responses that aren't eligible for caching at all. So when you strip Set-Cookie from a dynamic response, for instance, the rule fires whether or not the object is ever stored. This allows you to control what the client sees even when the response is not stored in cache. You can also strip ETag and Last-Modified , which is useful when those headers are misconfigured at the origin and causing thrash. This comes with a tradeoff: stripping both ETag and Last-Modified enables Smart Edge Revalidation for that response. If Cache Response Rules then add new validators, Cloudflare will not enable a Smart Edge Revalidation for browser conditional requests.

So stripping and modifying headers, even on dynamic requests, are a powerful new pattern that did not exist before on Cloudflare, but there can be additional configs to be aware of if you make these changes.

set_cache_tags lets you add , remove , or set cache tags used for purge by tag on the response. Tags can be static:

"action_parameters": {

"operation": "set",

"values": ["product-catalog", "storefront"]

}

Or computed from a response header expression:

"action_parameters": {

"operation": "add",

"expression": "split(http.response.headers[\"Surrogate-Keys\"][0], \",\", 64)"

}

That second form is the one that earns its keep during a CDN migration. If your previous CDN attached surrogate keys to responses using a header like Surrogate-Keys with a comma delimiter, you can translate them into Cloudflare's Cache-Tag format directly in the response phase.

The third argument to split() is the limit: the maximum number of elements in the resulting array can be between 1 and

set_cache_control is the action that does the most heavy lifting. You can set or remove individual directives:

For each directive you can also set cloudflare_only : true, which is the part that often surprises people:

"action_parameters": {

"s-maxage": {

"operation": "set",

"value": 86400,

"cloudflare_only": true

}

When cloudflare_only is true, the directive affects how Cloudflare caches the response, but the downstream Cache-Control value sent to the browser is left alone. This is the response-phase version of what CDN-Cache-Control gives you at the origin: cache the asset for 24 hours at Cloudflare, but tell the browser something else. The difference is that you're now doing it from a Rules surface in the Cloudflare dashboard, rather than asking the origin to set a separate header.

• Strip headers that break caching
• Manage cache tags
• Use a value comfortably larger than the realistic tag count per response. The value 1 would return the entire header as a single tag. Once tags exist on the response, purge-by-tag just works (and by “works” we mean usually in under 150 ms, globally ).
• Modify Cache-Control directives
• Duration directives: max-age , s-maxage , stale-if-error , stale-while-revalidate
• Qualified directives: private , no-cache (with optional header-name qualifiers)
• Boolean directives: no-store , no-transform , must-revalidate , proxy-revalidate , must-understand , public , immutable

Examples worth stealing

Below are some examples we thought could help show you the power of Cache Response Rules. Try them out, remix them, and share with others in the community so you can see how to achieve powerful cache customizations using Cache Rules with Cache Response Rules. More examples can be found in the docs .

Strip Set-Cookie from static asset extensions

Expression: http.request.uri.path.extension in {"js" "css" "woff2" "woff" "ttf" "png" "jpg" "svg"}

Action: set_cache_settings

strip_set_cookie: true

Why it works : The most common cause of "this should be cacheable but isn't" is a session middleware on the origin that attaches a Set-Cookie to every response. Stripping it for known-static extensions converts those responses to cacheable without any origin change.

Caveat : Only do this for asset types where the cookie is not semantically required. If your origin uses cookies to drive variant behavior on those URLs (very unusual but possible), strip selectively or scope stripping these headers by path.

Long-cache static assets in Cloudflare, shorter-cache them in the browser

Expression: http.request.uri.path.extension in {"js" "css" "woff2"}

Action: set_cache_control

s-maxage: set 2592000 (30 days), cloudflare_only=true

immutable: set

max-age: set 86400 (1 day), cloudflare_only=false

Why it works : Cloudflare holds the asset for a month and serves it from cache. Browsers see max-age=86400 and re-validate after a day. You decouple the two cache lifetimes without touching the origin.

Caveat : immutable tells browsers not to revalidate even on explicit refresh. Pair it only with versioned/hashed filenames.

Override no-cache on a known-static path

Expression: starts_with(http.request.uri.path, "/static/") and http.response.code eq 200

Action: set_cache_control

no-cache: remove

s-maxage: set 3600, cloudflare_only=true

Why it works : Framework defaults sometimes attach no-cache to every response. If you know /static/* is safe to cache, you can strip the directive and impose your own TTL (at Cloudflare only), without changing what the origin or any downstream cache sees.

Caveat : Be honest about what's actually static. If /static/ is sometimes used to serve user-specific content, narrow the match (extension, response header signal, content type).

Translate cache tags during a CDN migration

Expression: any(http.response.headers.names[*] == "Surrogate-Keys")

Action: set_cache_tags

operation: add

expression: split(http.response.headers["Surrogate-Keys"][0], ",", 64)

Why it works : A lot of CDN migration pain comes from origin tooling that emits cache-tag headers in another vendor's format. Instead of asking the origin team to ship a release that adds Cloudflare's Cache-Tag , translate the existing header in the response phase. Purge-by-tag on Cloudflare starts working immediately.

Caveat : The third argument to split() is the limit (1–128) on the resulting array size, not anything to do with the separator.

How to use Cache Response Rules

Dashboard

• Go to Cache > Cache Rules in the Cloudflare dashboard.
• Select Create rule and then Cache Response Rule .
• Choose a name and an expression. The expression builder exposes both request fields and response fields.
• Choose an action: Modify cache-control directives , Modify cache tags , or Strip headers .
• For directives, toggle Cloudflare only when you want the change to apply only to Cloudflare's view of the asset.
• Save as a draft to iterate, or deploy directly.

API

Rules in this phase live at:

/zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint

For further information about how to use Cache Response Rules including API and terraform examples, please see the documentation .

Use Cache Response Rules today

Cache Rules saw the request. Cache Response Rules see the response. Both give you even more control to build the perfect cache on Cloudflare. They are available on all plans today — go try them out!

Related tags

Application Services Cache Cache Rules CDN Optimization Product News

Follow on Social Media

• Cloudflare
• Alex Krivit