--- title: Cache-Control no-cache vs no-store vs private Explained description: "Cache-Control no-cache vs no-store vs private explained: no-cache revalidates, no-store prevents storage, and private limits caching." image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-01-40-36-5708-AM.jpeg --- [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜Learn โ–พ](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us) [โšก Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us) [๐ŸŽฌVideo & Streaming โ–พ](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿ”ด Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [๐Ÿ“บ VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [๐Ÿ’ฐ Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us) [๐Ÿญ Other Industries โ–พ](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ“บ Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [๐Ÿ’พ Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [๐Ÿ—๏ธ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [๐Ÿ“š AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [๐ŸŽฎ Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [๐Ÿ“ฑ Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [๐Ÿค– AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [๐Ÿ›๏ธ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [๐Ÿ“š E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [๐ŸŸ๏ธ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs โ–พ](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [โšกCompare โ–พ](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [Ratings & Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐Ÿ”’ Security โ–พ](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us) [๐Ÿ“ Case Studies](https://blog.blazingcdn.com/case-studies?hsLang=en-us) [๐Ÿ”Œ Integrations](https://blog.blazingcdn.com/integrations?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [Get Started](https://blazingcdn.com/sign-up-contact-form/) [Learn](https://blog.blazingcdn.com/en-us/tag/learn) [Learn - CDN Fundamentals](https://blog.blazingcdn.com/en-us/tag/learn-cdn-fundamentals) # Cache-Control no-cache vs no-store vs private Explained Vadym Borovskyi Nov 2, 2026, 2:43:18โ€ฏAM ![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-01-40-36-5708-AM.jpeg) Evaluated November 2026 against RFC 9111 and current vendor documentation. The short answer on no-cache vs no-store: no-cache means "store it, but confirm with the origin before every reuse," no-store means "never write it to any cache," and private means "only the end user's browser may keep it." Use no-store only for responses that must never be persisted, such as account statements or one-time tokens. Use no-cache for HTML entry points that must always be current. Use private for per-user responses that can still be reused in the browser for 60 seconds or more. Under RFC 9111, the HTTP caching standard in force as of 2026, a no-cache response may be stored by any cache but must be revalidated with the origin before each reuse, while a no-store response may not be stored at all. A successful no-cache revalidation returns a 304 Not Modified of a few hundred bytes instead of the full body, which is the entire performance difference between the two directives. The behavior that catches teams out sits at the edge. Varnish's built-in logic, nginx proxy\_cache and Cloudflare's default cache behavior all decline to store a response marked no-cache. On those layers, no-cache behaves like no-store, and every request becomes a full origin fetch. ## **What no-cache, no-store and private each permit a cache to do** Each directive answers three separate questions: may the response be stored, may it be reused without contacting the origin, and which caches the answer applies to. The table separates those questions. It also adds public with max-age=0 and must-revalidate as a reference point, because that combination is often confused with no-cache. | Directive | Browser may store | Shared cache (CDN, proxy) may store | Reuse without origin contact | Common default at the edge | | --- | --- | --- | --- | --- | | no-cache | Yes | Yes, per spec | Never; every reuse needs a 304 or 200 from origin | Not cached (bypass or hit-for-miss) | | no-store | No | No | Not applicable, nothing is stored | Not cached | | private | Yes | No | In the browser, until max-age expires | Not cached, unless a TTL floor overrides it | | public, max-age=0, must-revalidate | Yes | Yes | Never; stale on arrival, no serving stale on origin error | Usually not cached, because TTL is zero | The only directive that guarantees the CDN never holds a copy is no-store. no-cache and private are instructions about reuse and scope, and edge software implements them very differently from the specification. ## **no-cache vs no-store: what browsers actually do** Browsers implement both directives close to the specification. That is why the difference shows up in DevTools long before it shows up in CDN logs. ### Cache-Control no-cache in the browser: 304s, not full downloads With Cache-Control no-cache, the browser stores the response with its validators (ETag or Last-Modified). On the next navigation it sends If-None-Match or If-Modified-Since. If the origin answers 304, the browser renders the stored body. The cost is one round trip, but the transfer is a few hundred bytes. no-cache without an ETag or Last-Modified is the worst combination: the browser has nothing to validate with, so every request downloads the full body. ### Cache control no store and the back/forward cache With no-store, nothing is written to the HTTP cache, so every navigation is a full fetch. Chromium has historically excluded pages served with no-store from the back/forward cache (bfcache), which makes the back button reload the page instead of restoring it instantly. Chromium has been testing a relaxed version of this rule. Check the back/forward cache panel in DevTools instead of assuming either behavior. If you set no-store on every HTML page by habit, you pay this cost on every back navigation. ### Cache-Control private and per-user responses Cache-Control private keeps a response out of shared caches but lets the browser reuse it under normal freshness rules. "private, max-age=60" on a dashboard JSON call means one user's repeated tab switches cost zero requests for a minute. private is a caching instruction, not a confidentiality control. It does nothing against an intermediary that ignores it or is configured to override it. ## **What CDNs and reverse proxies actually do with each directive** Shared caches are allowed to be stricter than the specification, and most of them are. In practice, at the edge, no-cache usually means "do not cache." ### Varnish built-in logic The built-in VCL marks a backend response uncacheable if its Cache-Control contains no-cache, no-store or private (and no Surrogate-Control header is present). It then creates a hit-for-miss object that lasts 120 seconds. Requests for that object go straight to the backend without request coalescing for that window. A no-cache HTML page under load therefore fans out to origin at the full request rate. ### nginx proxy\_cache nginx does not cache upstream responses whose Cache-Control includes no-cache, no-store or private. It also skips responses that carry Set-Cookie. The proxy\_ignore\_headers directive can disable this check. That fix is dangerous on shared paths because it also ignores private. ### Amazon CloudFront Amazon CloudFront respects no-cache, no-store and private when the cache policy's minimum TTL (time to live) is 0. If the minimum TTL is greater than 0, CloudFront caches for at least that duration even when those directives are present. A minimum TTL of 1 second set "to absorb spikes" will therefore store private responses at the edge. That is a real cross-user leak risk on authenticated paths. ### Cloudflare Cloudflare's default cache behavior documentation states that it does not cache responses marked private, no-store, no-cache or max-age=0. Cloudflare also honors the CDN-Cache-Control header from RFC 9213. That header lets the origin give the edge a different lifetime from the one the browser sees, which is the clean way to get browser revalidation alongside edge caching. The same split is available on BlazingCDN through configuration rather than headers. Custom configurations and cache rules are set up per zone together with an engineer, and origin shield with request coalescing is included on every plan, as listed on the [**BlazingCDN features page covering cache rules and origin shield**](https://blazingcdn.com/features/). ## **Worked math: what no-cache costs your origin at 2,000 requests per second** Take one HTML entry point of 50 KB requested 2,000 times per second across the edge. That is 172.8 million requests per day. The three behaviors produce very different origin load. The figures below are arithmetic, not measurements. - **no-cache treated as bypass (typical edge default):** 172.8 million origin requests, times 50 KB, equals 8.64 TB of origin egress per day. - **no-cache implemented as store-and-revalidate with ETag:** still 172.8 million origin requests, but each 304 is about 300 bytes, so about 52 GB per day. Request volume is unchanged; bytes drop by about 99 percent. - **10-second edge TTL with origin shield and request coalescing:** at most one origin fetch per 10 seconds per shield, so 8,640 fetches and about 432 MB per day for a single shield. The gap between the first and third lines is roughly 20,000 times in origin bytes. It comes entirely from header and edge configuration, not from hardware. ## **Header recipes by content type** Most production mistakes come from applying a single directive site-wide. Match the directive to the content type instead: | Content | Cache-Control to send | Edge behavior to aim for | Why | | --- | --- | --- | --- | | Fingerprinted JS, CSS, video segments, installers | public, max-age=31536000, immutable | Cache for a year | The URL changes when the content changes | | HTML entry point, shared by all users | max-age=0, s-maxage=10, must-revalidate, plus ETag | 10-second edge TTL, browser revalidates | no-cache would bypass most edges | | Live HLS or DASH playlist | public, max-age of about half the segment duration | Short TTL with request coalescing | Thousands of players poll the same object | | Per-user API or dashboard JSON | private, max-age=0 or 60, plus ETag | Never stored; no TTL floor on this path | Browser reuse is safe; edge reuse leaks data | | Tokens, statements, password reset pages | no-store | Never stored | Nothing may persist on shared or local disk | no-store belongs on a small, sensitive slice of responses, not on HTML by default. Freshness for shared pages is better handled with a short s-maxage and validators. Most shared caches give s-maxage precedence over max-age, as RFC 9111 requires, which is what makes the second row work with a single header. Where the CDN supports RFC 9213, sending "Cache-Control: no-cache" alongside "CDN-Cache-Control: max-age=10" expresses the same intent more explicitly. ## **Trade-offs and failure modes** - **Redundant "no-cache, no-store, must-revalidate":** this legacy combination works, but no-store makes the other two directives moot. It also hides intent from whoever edits the header next. - **Short edge TTL vs freshness:** s-maxage=10 means a deploy can serve the old HTML for up to 10 seconds. Purge on deploy if that matters. - **TTL floors:** any minimum TTL above zero, on any CDN, overrides private. Scope floors to static paths only. - **Request-side no-cache:** a hard reload sends Cache-Control no-cache upstream. Many CDNs ignore it by default to protect the origin, so a forced reload in the browser does not prove the edge copy is fresh. - **Qualified forms:** no-cache or private with a field-name list, such as private="Set-Cookie", are valid but poorly implemented. Treat them as unqualified. - **Authorization headers:** shared caches must not store responses to requests carrying Authorization unless the response says public, s-maxage or must-revalidate. Adding public to an authenticated response opts it into edge caching. ## **How to verify cache behavior on your own stack** Request the same URL twice through the CDN and compare the Age header with the vendor's cache status header (X-Cache, CF-Cache-Status or the equivalent). A rising Age and a HIT on the second request confirm edge storage. In the browser, the DevTools Network panel shows "(disk cache)" for fresh reuse and status 304 for successful no-cache revalidation. For authenticated paths, request with two different sessions and confirm the second session never receives an Age above zero. ## **FAQ: Cache-Control no-cache vs no-store vs private** ### Is Cache-Control no-cache the same as no-store? No. no-cache allows a browser or CDN to store a response but requires revalidation with the origin before every reuse, while no-store forbids storing it anywhere. In browsers, no-cache usually produces cheap 304 responses when an ETag is present. Many CDNs, however, treat no-cache as uncacheable, so at the edge it often behaves like no-store. ### Does Cache-Control private stop a CDN from caching a response? It should, and most CDNs honor it by default, but configuration can override it. Amazon CloudFront, for example, caches responses marked private when the cache policy sets a minimum TTL above zero. Audit TTL floors and forced-caching rules on every authenticated path, because private only works when no edge rule overrides the origin's Cache-Control header. ### Should I use no-cache or no-store for HTML pages? Use neither by default for shared HTML pages; send max-age=0 with a short s-maxage and an ETag. This lets browsers revalidate on every navigation while the CDN absorbs load for a few seconds. Reserve no-store for pages with sensitive per-user data, and accept that it may disable the back/forward cache in Chromium browsers. ### Why does my CDN not cache responses with Cache-Control no-cache? Most CDN and proxy defaults, including Varnish's built-in logic, nginx proxy\_cache and Cloudflare's default behavior, skip storing no-cache responses rather than storing and revalidating them. The specification permits this. To cache at the edge while keeping browsers fresh, use s-maxage, the RFC 9213 CDN-Cache-Control header, or an edge cache rule for that path. ## **Audit your Cache-Control headers against real edge logs this week** Export one day of CDN logs and group requests by Cache-Control value and cache status. Flag every no-cache response served as MISS or BYPASS, and multiply the request count by the average body size: that number is the origin egress your headers are creating. Then list every path that combines private or Authorization with a nonzero minimum TTL, and fix those first, because they are data leaks rather than performance problems. Rerun the two-session check above on each fixed path. For high-volume static delivery where you want edge TTLs set independently of browser headers, BlazingCDN zones are configured together with an engineer, and onboarding on the [**BlazingCDN Anycast CDN with custom cache rules**](https://blazingcdn.com/anycast-cdn/) takes about one hour. Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained) [๐•](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained&text=) [โœ‰](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3ECache-Control%20no-cache%20vs%20no-store%20vs%20private%20Explained%3C/span%3E&body=https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained) ![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png) *Heavy traffic.* Light bill. The CDN for video and large traffic Their monthly bill vs ours - 20 TBFastly $2,087**$92.50** - 50 TBCDN77 $990**$215** - 200 TBCloudFront $11,965**$765** Published list prices, Aug 2026 [Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc) ## Related posts [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-01-25-13-6615-AM.jpeg)](https://blog.blazingcdn.com/en-us/cloudimage-cdn-vs-blazingcdn-image-optimization?hsLang=en-us) Pricing - Pricing & Costs ### [Cloudimage vs BlazingCDN in 2026: Image CDN Cost and Features](https://blog.blazingcdn.com/en-us/cloudimage-cdn-vs-blazingcdn-image-optimization?hsLang=en-us) Evaluated November 2026: if you need on-the-fly AVIF and WebP conversion, smart cropping and responsive helpers from a ... Nov 2, 2026, 2:27:55โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/cloudimage-cdn-vs-blazingcdn-image-optimization?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-02-2026-12-55-10-9390-AM.jpeg)](https://blog.blazingcdn.com/en-us/cdn-for-live-courses-setup-strategy?hsLang=en-us) Learn ### [CDN for Live Courses: Setup & Strategy](https://blog.blazingcdn.com/en-us/cdn-for-live-courses-setup-strategy?hsLang=en-us) Live course streaming in 2026 is a one-to-many video problem with a tight latency budget. Classic HLS with 6-second ... Nov 2, 2026, 1:58:04โ€ฏAM [Read more](https://blog.blazingcdn.com/en-us/cdn-for-live-courses-setup-strategy?hsLang=en-us) [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [๐Ÿ“˜ Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [๐Ÿ“Š Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [๐ŸŽฌ Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [๐Ÿญ Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [๐Ÿ’ฐ Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [โšก Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [๐Ÿ”’ Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [๐Ÿ› ๏ธ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [โœ๏ธ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us) in f ๐• โœ‰ Copyright ยฉ BlazingCDN |. All rights reserved. ```json { "@context" : "https://schema.org", "@id" : "https://blazingcdn.com/#organization", "@type" : "Organization", "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.", "logo" : { "@id" : "https://blazingcdn.com/#logo", "@type" : "ImageObject", "height" : 560, "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png", "width" : 560 }, "name" : "BlazingCDN", "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ], "url" : "https://blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/#website", "@type" : "WebSite", "inLanguage" : "en-US", "name" : "BlazingCDN Blog", "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "url" : "https://blog.blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained#article", "@type" : "BlogPosting", "author" : { "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person", "@type" : "Person", "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg", "jobTitle" : "Chief Product and Marketing Officer", "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ], "name" : "Vadym Borovskyi", "sameAs" : [ "https://www.linkedin.com/in/axelt/" ], "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn", "worksFor" : { "@id" : "https://blazingcdn.com/#organization" } }, "dateModified" : "2026-11-02T01:43:18Z", "datePublished" : "2026-11-02T01:43:18Z", "description" : "Cache-Control no-cache vs no-store vs private explained: no-cache revalidates, no-store prevents storage, and private limits caching.", "headline" : "Cache-Control no-cache vs no-store vs private Explained", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Nov-02-2026-01-40-36-5708-AM.jpeg", "inLanguage" : "en-us", "isPartOf" : { "@id" : "https://blog.blazingcdn.com/#website" }, "mainEntityOfPage" : { "@id" : "https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained", "@type" : "WebPage" }, "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "wordCount" : 2167 } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained#breadcrumb", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained", "name" : "Cache-Control no-cache vs no-store vs private Explained", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/cache-control-no-cache-vs-no-store-vs-private-explained#faq", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "No. no-cache allows a browser or CDN to store a response but requires revalidation with the origin before every reuse, while no-store forbids storing it anywhere. In browsers, no-cache usually produces cheap 304 responses when an ETag is present. Many CDNs, however, treat no-cache as uncacheable, so at the edge it often behaves like no-store." }, "name" : "Is Cache-Control no-cache the same as no-store?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "It should, and most CDNs honor it by default, but configuration can override it. Amazon CloudFront, for example, caches responses marked private when the cache policy sets a minimum TTL above zero. Audit TTL floors and forced-caching rules on every authenticated path, because private only works when no edge rule overrides the origin's Cache-Control header." }, "name" : "Does Cache-Control private stop a CDN from caching a response?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Use neither by default for shared HTML pages; send max-age=0 with a short s-maxage and an ETag. This lets browsers revalidate on every navigation while the CDN absorbs load for a few seconds. Reserve no-store for pages with sensitive per-user data, and accept that it may disable the back/forward cache in Chromium browsers." }, "name" : "Should I use no-cache or no-store for HTML pages?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Most CDN and proxy defaults, including Varnish's built-in logic, nginx proxy_cache and Cloudflare's default behavior, skip storing no-cache responses rather than storing and revalidating them. The specification permits this. To cache at the edge while keeping browsers fresh, use s-maxage, the RFC 9213 CDN-Cache-Control header, or an edge cache rule for that path." }, "name" : "Why does my CDN not cache responses with Cache-Control no-cache?" } ] } ```