CDN and edge network: cache correctness before hit ratio

A CDN request crosses DNS, TLS, security policy, key normalization and cache freshness. Only a miss or revalidation reaches shield and origin. Responses must be cached according to HTTP directives and the exact dimensions that change representation.

Key and authorization safety

Include only bounded, semantically required query/header/cookie dimensions. Omitting a dimension used by the origin can mix responses; including unique session values fragments the cache. Never share a personalized response under a public key. Forwarding Authorization without putting it in the key is safe only when caching is disabled or authorization is otherwise enforced before reuse.

Freshness and invalidation

Prefer content-versioned URLs for immutable assets. For mutable paths, issue a targeted invalidation and observe its provider status until Completed; do not teach a fixed “propagates in N minutes” claim. Serving stale on origin failure is an explicit stale-if-error/policy decision, inappropriate for some data.

TLS 1.3 0-RTT sends early data on a resumed connection while the handshake continues. It does not skip TLS and can be replayed, so allow it only for replay-safe requests with application idempotency and anti-replay controls.

A hit avoids origin requests and compute, but bytes still travel from CDN edge to viewer and can incur viewer-delivery charges.

Scenarios

Sources

• CloudFront cache keys
• HTTP caching, RFC 9111
• CloudFront invalidation status
• TLS 1.3, RFC 8446
• CloudFront delivery and pricing semantics