When a CDN edge receives a request, it computes a cache key — typically the host, path, and selected headers and query parameters — and uses that key to look up the entry in its cache. Two requests with the same key share one entry; two requests with different keys are stored separately. The default key for most CDNs is just the URL, but defaults can be configured to include or exclude specific headers, query parameters and cookies.
The classic CHR-killing mistake is letting a session ID or random tracking parameter become part of the cache key. If https://example.com/segment.m4s?session=12345 is treated as different from https://example.com/segment.m4s?session=67890, every viewer gets their own cache entry. Origin fetches go from one-per-segment to one-per-viewer, and CHR collapses to near zero. Every streaming traffic engineer has a story of finding a cookie or query param in the cache key during a CHR investigation.
The fix is cache-key normalisation: explicit rules at the CDN layer for what to include and what to ignore. The standard rule for streaming is "cache by URL path only, ignore query string, ignore most headers, retain Accept-Encoding". Signed-URL setups need careful handling — the signature must be validated but not be part of the cache key, which usually means a separate "verify then strip" rule. Every CDN exposes this as a configuration; the difficulty is remembering to do it before traffic ramps.
