CDN Cache Keys and Tokenized URLs Explained

Why this matters

The cache-hit ratio — the share of delivered bytes that come from a CDN's edge instead of your origin — is the number that decides whether a streaming platform's delivery bill is sustainable or ruinous, and both of the topics in this article move it directly. Get the cache key wrong and a platform that should run at a 95% hit ratio runs at 30%, multiplying origin traffic and cost by an order of magnitude while viewers buffer. Get tokenized URLs wrong and you either leak premium content to anyone who copies a link, or you protect it in a way that quietly destroys the cache you were relying on to afford delivery at all. This article is for the founder, product manager, or streaming engineer who needs to understand both levers well enough to brief a CDN vendor, read a delivery bill, and avoid the configuration that turns a launch into an origin meltdown. By the end you will be able to look at a video URL and say what belongs in the cache key, what belongs in the token, and why the two must never be the same field.

A one-minute refresher on the edge cache

This article builds on the cache mechanics we laid out in how a CDN delivers video; here is the part you need in front of you.

A content delivery network — the global fleet of caching servers, called a CDN, that holds copies of your video close to viewers — works like a chain of corner stores stocked from one central warehouse. Your origin is the warehouse: the authoritative server that holds the one true copy of every file. The CDN's edge servers are the corner stores: thousands of machines near viewers that keep copies of whatever their neighbourhood asks for. When a viewer requests a video segment and the nearby edge already has it, that is a cache hit — served instantly, cheaply, without bothering the warehouse. When the edge does not have it, that is a cache miss, and the edge fetches it from the origin first, which is slow and counts against the recurring cost of sending bytes out of the origin.

The economic engine is the offload ratio — the share of bytes served from the edge cache rather than the origin. One popular segment, cached once at an edge, can satisfy thousands of viewers from that single stored copy. That convergence is the whole reason streaming is affordable. Everything in this article is ultimately about protecting it: the cache key is how the edge knows two viewers want the same stored copy, and a tokenized URL is how you keep the wrong viewers from getting it — without accidentally telling the edge that every viewer wants a different copy.

The cache key: how the edge decides "have I seen this before?"

When a request reaches an edge server, the edge has to answer one question before it does anything else: do I already have the thing this request is asking for? The way it answers is by computing a cache key — a short identifier derived from the request — and looking that key up in its local store. Same key as a previous request, and the stored object is still fresh? Cache hit. New key? Cache miss, go to origin.

The HTTP caching standard is precise about what that key is. Under RFC 9111 (the 2022 HTTP Caching specification, which replaced RFC 7234), "the 'cache key' is the information a cache uses to choose a response," and the baseline is simple: a cache "[uses] the URI as the cache key." In plain terms, the default cache key is the request method plus the full URL — for video, effectively the hostname and the path. Amazon's CloudFront documentation states the same default concretely: the cache key is the distribution's domain name plus "the URL path of the requested object," and "other values from the viewer request are not included in the cache key, by default." Two requests for /movie/ep1/segment_00042.m4s produce the same key and share one cached object, even if their query strings, User-Agent headers, and cookies differ completely.

This default is exactly right for video, and to see why, recall how streaming media is structured. Your video is not one file; it is a manifest (a small index file) plus hundreds or thousands of short segments (a few seconds of video each), and each segment is its own separately-addressable HTTP resource with its own URL — the structure we cover in packaging: CMAF, HLS, and DASH. The HLS specification, IETF RFC 8216, defines the playlist as a text file in which "each line is a URI that identifies a media segment or a Playlist file." MPEG-DASH, standardized as ISO/IEC 23009-1, generates segment URLs deterministically from a SegmentTemplate (replacing $Number$ with the segment index) under a BaseURL. Either way, the addresses are stable and identical for every viewer: segment 42 of episode 1 at the 1080p rendition has one URL, the same for everyone. That stability is what lets one cached copy serve the world.

There is one sanctioned way to make the key depend on more than the URL: the Vary response header. RFC 9111 says a cache "might incorporate additional material into the cache key" using the Vary header, which lists request headers whose value changes the response — this is sometimes called a secondary cache key. If your origin returns different bytes to clients that sent Accept-Encoding: gzip, it sets Vary: Accept-Encoding, and the edge then keys on the path and that header. Used with discipline (a known, low-cardinality header), Vary is safe. Used carelessly — Vary: User-Agent, which has thousands of distinct values — it shatters the cache the same way a per-viewer key does. RFC 9111 even singles out the pathological case: a stored response whose Vary value is * "always fails to match," meaning it can never be reused.

Figure 1. What belongs in the cache key and what must stay out. The path identifies the segment every viewer shares; tokens, session IDs, and high-cardinality headers identify the individual viewer and belong nowhere near the key.

The million-dollar mistake: a per-viewer cache key

Here is the failure that has melted more streaming launches than any other, and it follows directly from everything above.

To control access or to attribute analytics, a team appends something per-viewer to every media URL — a session ID, a signed token, a ?user=... parameter — and then, by misconfiguration or by leaving a default on, lets that parameter into the cache key. Now the edge treats /segment_00042.m4s?token=AAA and /segment_00042.m4s?token=BBB as two different objects, because their keys differ. The first viewer's request is a miss that fetches segment 42 from the origin and caches it under key-with-token-AAA. The second viewer, with token BBB, is also a miss — the edge has segment 42, but not under this key — so it fetches the identical bytes from the origin again. Every viewer forks every segment into a private copy. The shared cache that was supposed to serve thousands from one stored object now stores thousands of identical objects, each used once.

Walk the arithmetic out loud, because the scale is the point. Take a service streaming a popular live episode to 100,000 concurrent viewers, each pulling a fresh 4-second segment, so the edge fields about 25,000 segment requests per second.

With a correct cache key (path only):
  one segment is fetched from origin ONCE, then served from edge to all.
  origin fetches per segment ≈ 1
  offload ratio ≈ 99.99%  → origin barely notices

With a per-viewer cache key (token in the key):
  every viewer's request is a unique key → a unique origin fetch.
  origin fetches per segment ≈ 100,000
  offload ratio ≈ 0%  → origin must serve 25,000 req/s of video

A correctly-keyed origin serves a trickle; the same origin behind a per-viewer key is asked to serve the entire audience directly, at the full bitrate, all at once. It cannot, so it falls over — and it falls over precisely during the premiere you cannot re-run. Vendor field reports describe the same collapse in less dramatic terms: putting token parameters into the cache key can drop a 98% hit ratio to under 40% "within minutes." The cause is not a bug in the CDN; it is RFC 9111 working exactly as written. Each edge is a separate shared cache that must be populated per distinct key, and you handed it a distinct key per viewer.

Figure 2. The per-viewer-key collapse on a 100,000-viewer segment. A correct path-only key needs one origin fetch and offloads ~99.99%; a token in the key needs an origin fetch per viewer and offloads ~0%. Figures illustrative.

The fix is a single principle, and the rest of this article is its application: the cache key identifies the content; the token identifies the viewer; never put the second thing in the first.

Tokenized URLs: locking the door without re-cutting every key

Now the opposite problem. The same stable, shared segment URL that makes caching cheap also makes the content easy to steal: if /movie/ep1/1080p/segment_00042.m4s is a fixed address, anyone who copies it can fetch your premium video, and they can paste the link into a forum for the world. You need a way to admit paying viewers and turn away everyone else — at the edge, before any bytes are served, and without a per-viewer cache key.

That mechanism is the tokenized URL, also called a signed URL: a normal content URL with an extra, cryptographically signed permit attached, usually as a query string. Think of it as a timed wristband at a festival. The wristband is not the ticket office and it is not the stage — it is a quick-to-check token that the gate staff (the edge) can validate on sight: is this band genuine (the signature checks out), is it still valid (not past its expiry), and does it admit you to this stage (the path it was issued for)? A genuine, unexpired band gets you in; a forged or expired one is refused at the gate. Crucially, the edge can check the wristband and then serve the same shared cached segment it serves everyone — the band controls the door, not which copy you get.

Concretely, the platform's application server decides a viewer is entitled (signed in, subscription active, rental paid), then computes a signature — typically an HMAC (a keyed hash) or an RSA/ECDSA digest — over a canonical string that names the resource path and an expiry timestamp, optionally pinned to a client IP range or geography. The viewer's player sends the token with each request; the edge recomputes or verifies the signature with a shared secret or public key, checks the expiry and any constraints, and admits or rejects the request. No database lookup, no round-trip to your servers — the permit is self-contained, which is why it is fast enough to check on every one of those 25,000 requests per second.

A tokenized URL is access control, not encryption. It decides who may fetch the bytes; it does not scramble the bytes themselves. A determined attacker who is admitted can still capture what they receive. For premium catalogs that need to stop the decrypted stream from being copied, token auth is the first gate, with digital rights management (DRM) — the system that encrypts the stream and controls the keys — layered on top; we cover where that line falls in why DRM exists and what it protects. Akamai frames it as a protection spectrum: open access, then token auth, then geo-blocking, then HTTPS, then media encryption, then full DRM — each a stronger and costlier layer. Token auth is the cheap, universal first step that every paid platform needs.

Figure 3. The tokenized-URL flow. The app server signs a short-lived permit; the edge validates the signature, expiry, and path before serving; the cache key still uses only the path, so all entitled viewers share one cached copy.

How the major CDNs implement it

The mechanism is standard; the field names differ. Naming a few keeps the vendor pitches legible, and the comparison matters because a steered viewer may move between them (more on that below).

Amazon CloudFront offers two forms. Signed URLs carry the permit in the query string and come in a canned policy (one file, expiry only) or a custom policy (wildcard resource paths, optional start time, and an IP-range restriction); CloudFront verifies the signature with RSA 2048 or ECDSA 256 keys. Its documentation warns that "if you add a query string to a signed URL after signing it, the URL returns an HTTP 403" — the signature covers the query string. Signed cookies carry the same permit in an HTTP cookie (governed by the cookie standard RFC 6265) instead of the URL, which is the better fit for streaming: you sign once, the browser attaches the cookie to every segment request automatically, and — because cookies are not part of the default cache key — the segments stay shared. CloudFront's own guidance is to use signed cookies "to provide access to multiple restricted files," which is precisely a video's many segments.

Akamai uses a two-token model that maps neatly onto how streaming sessions actually work. An access token (the "short token," delivered as hdnts) is generated by your origin to prove the session is authenticated; the edge validates its HMAC and checks it has not expired and that its access-control list covers the requested URL, plus an optional client-IP check. Once that passes, Akamai issues a session token (the "long token," hdntl) that is valid for the whole stream, and the player returns it on each subsequent segment. The session token's lifetime is "the full duration of the requested media item, or one day (86,400 seconds), whichever is shorter." For players or devices that block third-party cookies, Akamai supports a cookie-less mode that puts the token in the URL query string instead — useful, but exactly the case where cache-key hygiene becomes critical.

Cloudflare Stream makes a video require a signed token so it "can no longer be accessed publicly with only the video ID," and validates that token at the edge on every request, blocking anything without a valid one. For high volume it lets you mint tokens yourself from a signing key rather than calling its API per view — the same self-contained-permit idea.

CDN / mechanism	Where the token lives	Signature	Expiry / scope controls	Cache-key safe by default?
CloudFront signed URL	Query string	RSA 2048 / ECDSA 256	Expiry; custom policy adds start time + IP range	Yes — query strings excluded from key unless you add them
CloudFront signed cookie	HTTP cookie (RFC 6265)	RSA 2048 / ECDSA 256	Expiry; multi-file via wildcard policy	Yes — cookies excluded from key by default
Akamai access + session token	hdnts then hdntl; cookie or query string	HMAC (shared secret)	Session TTL = media duration or 86,400 s	Yes if token params are excluded from the cache key
Cloudflare Stream signed URL	Signed token on the URL	Key-signed token	Expiry; optional geo/IP rules	Yes — Stream manages keying for you

Table 1. How four common tokenized-URL schemes place and check the permit. The "cache-key safe by default?" column is the one that decides your hit ratio: every scheme can be configured to keep the token out of the key, but a query-string token demands you confirm it.

Reconciling the two: access control AND a high hit ratio

The two halves of this article pull in opposite directions only if you let them. The reconciliation is to make the token validated but invisible to the key: the edge inspects the permit as an access gate, then computes the cache key from the path alone, so all entitled viewers converge on one stored object.

Three practices get you there, and they reinforce each other. First, prefer signed cookies (or signed headers) over query-string tokens for the segments. A cookie rides along with every request automatically and is excluded from the cache key by default on every major CDN, so the path keys cleanly. This is why CloudFront recommends signed cookies for multi-file content and why cookie-based session tokens are the default elsewhere.

Second, when you must use a query-string token — for players that drop cookies, or for shareable links — explicitly exclude the token parameters from the cache key. Every serious CDN exposes this control: CloudFront's default already omits query strings (you opt in per parameter via a cache policy, so simply do not add the token); Akamai provides a dedicated "Cache Key Query Parameters" behaviour to list which parameters count toward the key, letting you validate the token while ignoring it for keying. The edge still reads the token; it just does not let it fork the object.

Third — the practical 2026 consensus for large catalogs — sign the manifest, not every segment. Issue one short-lived signed permit (URL or cookie) at the manifest, scoped by a wildcard or path prefix to cover the segments beneath it, and let the segment requests ride the session cookie or the wildcard. You authenticate once per session instead of stamping a per-segment token, the segments share one cache key, and the blast radius of a leaked link is one short window rather than your whole catalog. The trade-off to weigh is granularity: per-manifest signing cannot revoke a single segment mid-stream, which is usually fine for video-on-demand and is handled separately for live.

Token parity across CDNs — the multi-CDN trap

If you run more than one CDN — the architecture we cover in multi-CDN architecture and orchestration — tokenized URLs acquire a sharp edge. Each CDN secures URLs with its own token scheme and its own secret, so a viewer steered mid-stream from CDN A to CDN B can be rejected at B's gate because the token they hold was minted for A. The symptom is maddening: playback that works until a steering event, then a wall of 403s. The industry fix is a Common Access Token (CAT), an effort standardized by the Streaming Video Technology Alliance and CTA-WAVE to express one portable permit every participating CDN can validate. If multi-CDN is on your roadmap, design token parity in from the start rather than discovering it during a failover.

Cache invalidation: changing what the edge already stored

Caching is a promise to not re-fetch, which raises the obvious question: how do you change something the edge is already serving? You have three levers, in rising order of force, and for video you reach for them surprisingly rarely.

The gentlest is time-to-live (TTL) expiry. Every cached object carries a freshness lifetime, set by the origin via the Cache-Control: max-age or Expires header; RFC 9111 defines a "fresh" response as one whose age has not exceeded that lifetime, after which the edge revalidates with the origin. For video this does most of the work for free: immutable media segments get a very long TTL (they never change once published — segment 42 is segment 42 forever), while the live manifest gets a short TTL (a few seconds, because it grows with each new segment). Set those two correctly and you rarely purge anything.

The firmer lever is explicit purge — telling the CDN to drop an object now. Purge by exact URL is the blunt version. The scalable version, pioneered by Fastly, is the surrogate key (a "cache tag"): you stamp related objects with a shared label via a Surrogate-Key response header, then purge everything carrying that label in one call — for example, tag every rendition and segment of a title with its content ID and purge the title in a single request (Fastly purges up to 256 keys per batch). This is how you yank a video that was published by mistake or hit with a takedown, without enumerating its thousands of segment URLs.

The subtlest lever is soft purge — marking objects stale rather than deleting them. A soft-purged object can still be served instantly while the edge fetches a fresh copy in the background (the stale-while-revalidate pattern), so viewers never wait on a cache miss. For a high-traffic catalog this is the safe default for content updates: you refresh without ever exposing the origin to a stampede of simultaneous misses.

A word of discipline that ties back to the cache key: the cleanest way to "change" a video asset is usually not to purge it but to publish it at a new path (a new version segment or a cache-busting suffix in the filename, not the query string). A new path is a new cache key that fills naturally, with no purge and no risk of a half-updated edge. Purging is for removal and emergencies; versioning is for change.

Figure 4. The cache-control levers, by scope and force. TTL does the routine work; surrogate-key purge removes a whole title in one call; soft purge refreshes without a miss storm; new paths beat purging for ordinary changes.

Prefetch: filling the edge before the crowd arrives

The mirror image of invalidation is prefetch (also called prewarming): putting content into the edge cache before viewers ask for it, so the first request is already a hit. For on-demand catalogs the routine flow does this naturally — the first viewer of a segment warms it for the rest. The case that needs deliberate prewarming is the live premiere, where 100,000 viewers hit segment 1 in the same second; without a warm edge, that simultaneous burst of misses — the "thundering herd" — all reach toward the origin at once, which is exactly what an origin shield exists to absorb.

Two techniques tame it, both of which lean on the cache key being correct. Edge prefetch pushes or pulls the opening segments and the manifest into edge caches ahead of the start, so the herd lands on hits. Origin-assist prefetch, offered by Akamai among others, lets the origin hint the next segment so the edge fetches it just ahead of demand for live. Neither helps if the cache key is per-viewer — you cannot pre-warm a copy that every viewer will key differently — which is one more reason the key hygiene in this article is the foundation everything else stands on. We go deep on surviving the simultaneous live start in live event delivery and the premiere spike.

Common mistakes that quietly wreck delivery

Most cache-and-token failures are configuration, not architecture, and they share a habit of looking fine in a one-viewer test and breaking at scale.

The headline error is the per-viewer cache key already dissected: any session ID, auth token, or analytics parameter allowed into the key forks every segment per viewer and collapses the hit ratio. Its quiet cousin is Vary abuse — Vary: User-Agent or Vary: Cookie does the same shattering through the secondary cache key, so vary only on low-cardinality headers you truly serve differently. A third is signing every segment with a query-string token and keying on it — the worst of both worlds, combining maximum token overhead with maximum cache fragmentation; sign the manifest and prefer cookies instead. A fourth is purging when you should version — hammering purge for routine content changes invites half-updated edges and origin load, where a new path would have filled cleanly. And in multi-CDN, forgetting token parity leaves steered viewers locked out at the second network's gate. Every one of these is invisible in a single-user QA pass and obvious in the origin-egress graph on launch night.

Where Fora Soft fits in

The cache-hit ratio is a scale-and-cost number before it is a technical one: at petabyte volumes it is the difference between a delivery bill that scales with your audience and one that scales with your origin, and both the cache key and the token sit directly on it. Fora Soft has built video streaming, OTT/Internet TV, e-learning, telemedicine, and video surveillance software since 2005, across 625+ shipped projects for 400+ clients, and that work centres on exactly this kind of delivery engineering: designing cache keys that keep segmented media shared, wiring tokenized access — signed cookies or signed URLs — that gates paying viewers without fragmenting the cache, keeping token validation working across a multi-CDN steer, and prewarming the edge so a live premiere lands on hits instead of melting an origin. When a media company needs a delivery path whose hit ratio survives a real, growing, global audience, that cache-and-access engineering is the capability we bring.

What to read next

• How a CDN delivers video: origin, edge, and cache
• CDN cost engineering: egress, commits, and the 95th percentile
• Multi-CDN architecture and orchestration

Call to action

• Talk to a streaming engineer — book a 30-minute scoping call to talk through your cdn cache key plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Edge Cache & Token Design Checklist — A one-page checklist to work through before you ship a streaming catalog: design the cache key for segmented media (path only; keep tokens, session IDs, and high-cardinality headers out), choose where the token lives (signed cookie vs….

References

1. RFC 9111 — HTTP Caching — IETF, June 2022. Defines the cache key ("the information a cache uses to choose a response"; "use the URI as the cache key"), the Vary secondary cache key (and that Vary: * "always fails to match"), and the freshness-lifetime / max-age model behind TTL. Replaces RFC 7234. Tier 1 (official standard). https://www.rfc-editor.org/rfc/rfc9111.html (accessed 2026-06-16)
2. RFC 8216 — HTTP Live Streaming (HLS) — IETF (R. Pantos, Ed.), August 2017. Defines the M3U playlist in which "each line is a URI that identifies a media segment or a Playlist file" — the basis for why each segment is a separately-cacheable HTTP resource with a stable, shared URL. Tier 1 (format specification). https://www.rfc-editor.org/rfc/rfc8216 (accessed 2026-06-16)
3. ISO/IEC 23009-1 — Dynamic Adaptive Streaming over HTTP (MPEG-DASH) — ISO/IEC, 2022 edition. Defines deterministic segment addressing via SegmentTemplate ($Number$/$Time$) and BaseURL, producing stable per-segment URLs identical across viewers. Tier 1 (format specification). https://www.iso.org/standard/83314.html (accessed 2026-06-16)
4. RFC 6265 — HTTP State Management Mechanism (Cookies) — IETF, April 2011. The cookie standard behind signed cookies: Set-Cookie/Cookie semantics that let a single signed permit ride every subsequent segment request automatically. Tier 1 (official standard). https://www.rfc-editor.org/rfc/rfc6265 (accessed 2026-06-16)
5. Understand the cache key — Amazon CloudFront Developer Guide, 2026. The default cache key (distribution domain + URL path; other request values excluded by default), the explicit warning that high-cardinality values (User-Agent, session cookies) cache duplicate objects and lower the hit ratio, and the cache-policy / origin-request-policy split. Tier 3 (first-party CDN engineering). https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-the-cache-key.html (accessed 2026-06-16)
6. Use signed URLs / Use signed cookies — Amazon CloudFront Developer Guide, 2026. Canned vs custom signed-URL policies, RSA 2048 / ECDSA 256 verification, expiry and IP-range scope, the "403 if you append a query string after signing" rule, and the recommendation to use signed cookies for multiple restricted files. Tier 3 (first-party CDN engineering). https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html (accessed 2026-06-16)
7. Token Authentication — Akamai Adaptive Media Delivery TechDocs, 2026. The two-token hybrid model (access "short" token hdnts from origin; session "long" token hdntl issued by the edge), HMAC validation with ACL/URL and optional client-IP checks, the session-TTL rule (media duration or 86,400 s, whichever is shorter), the protection spectrum (open → token → geo → HTTPS → media encryption → DRM), and cookie-less query-string tokens for HLS. Tier 3 (first-party CDN engineering). https://techdocs.akamai.com/adaptive-media-delivery/docs/add-token-auth (accessed 2026-06-16)
8. Cache Key Query Parameters — Akamai Adaptive Media Delivery TechDocs, 2026. The behaviour that controls which query parameters enter the cache key — the mechanism for validating a query-string token while excluding it from the key so segments stay shared. Tier 3 (first-party CDN engineering). https://techdocs.akamai.com/adaptive-media-delivery/docs/cache-key-query-param-amd (accessed 2026-06-16)
9. Secure your Stream (signed URLs) — Cloudflare Stream docs, 2026. Making a video require a signed token so it cannot be accessed with the video ID alone, edge validation of the token on every request, and self-signing from a signing key for high-volume token generation. Tier 3 (first-party CDN engineering). https://developers.cloudflare.com/stream/viewing-videos/securing-your-stream/ (accessed 2026-06-16)
10. Purging with surrogate keys / Soft purges — Fastly Documentation, 2026. Surrogate keys (cache tags) via the Surrogate-Key header for purging related objects in one call (up to 256 keys per batch), and soft purge (mark stale, serve-while-revalidate) for refreshing without a miss storm. Tier 3 (first-party CDN engineering). https://www.fastly.com/documentation/guides/full-site-delivery/purging/purging-with-surrogate-keys/ (accessed 2026-06-16)
11. Multi-CDN Delivery — Streaming Video Technology Alliance, October 2024. Context for cross-CDN token parity and the Common Access Token (CAT) effort with CTA-WAVE — one portable permit every participating CDN can validate, so a steered viewer is not locked out. Tier 5 (industry alliance). https://www.svta.org/2024/10/24/multi-cdn-delivery/ (accessed 2026-06-16)
12. CDN Signed URLs and Token Authentication Explained — BlazingCDN, 2026. Used only to corroborate the field-observed magnitude of the per-viewer-key failure (a 98% hit ratio dropping below 40% "within minutes") and the sign-the-manifest-not-every-segment practice. Tier 7 (vendor blog) — illustrative, not a spec source. https://blog.blazingcdn.com/en-us/cdn-signed-urls-and-token-authentication-explained (accessed 2026-06-16)

Source note (per §4.3.2): the caching mechanics trace to tier-1 standards — RFC 9111 for the cache key, Vary/secondary key, and freshness (refs 1), with the segment-URL structure grounded in RFC 8216 for HLS (ref 2) and ISO/IEC 23009-1 for DASH (ref 3), and signed cookies resting on RFC 6265 (ref 4). The vendor mechanisms (CloudFront, Akamai, Cloudflare, Fastly; refs 5–10) are cited first-party for "what actually ships" and dated, since CDN feature sets change. Where popular posts imply a token must live in the URL (and by implication the key), the article follows the RFC 9111 shared-cache model and the CloudFront/Akamai cache-key controls that keep the token out of the key; the one vendor-blog figure (ref 12) is labelled illustrative, not authoritative.