Edge-Control
The HTTP Edge-Control response header is an unofficial header used to control Caching and content handling at CDN edge servers, primarily on Akamai's network.
Usage
Origin servers send Edge-Control to instruct Akamai edge nodes on how to cache and deliver a response. The header functions as a CDN-layer override, operating independently of Cache-Control directives intended for browsers. This separation allows aggressive edge caching policies without affecting client-side caching behavior.
Akamai introduced Edge-Control as part of its
proprietary edge infrastructure. The header is consumed
and stripped by the edge server before the response
reaches the client. Meta (Facebook, Instagram) and other
large-scale Akamai customers rely on this header
extensively. The most common pattern observed in
production is a simple max-age directive on static
resources and robots.txt files.
For multi-CDN setups or vendor-neutral configurations, Surrogate-Control and CDN-Cache-Control offer similar edge-layer cache control with broader CDN support.
Directives
no-store
The no-store directive tells the edge server to bypass
caching entirely. Every request passes through to the
origin server. This is the edge-layer equivalent of the
Cache-Control no-store directive.
Edge-Control: no-store
max-age
The max-age directive sets the freshness lifetime in
seconds for the edge cache. The edge server stores and
serves the cached response until the specified duration
expires.
Edge-Control: max-age=86400
cache-maxage
The cache-maxage directive sets the edge cache lifetime
using a duration format with time unit suffixes.
Accepted units include s (seconds), m (minutes),
h (hours), and d (days). This offers a more readable
alternative to max-age for longer durations.
Edge-Control: cache-maxage=7d
!no-store
The !no-store directive forces the edge server to cache
the response even when Cache-Control
includes no-store. This override is useful when the
origin sends browser-facing no-store directives but still
wants the CDN layer to cache the content.
Edge-Control: !no-store
downstream-ttl
The downstream-ttl directive sets a freshness lifetime
for downstream caches sitting between the Akamai edge
and the client, such as intermediate proxies or parent
cache tiers. The value supports time unit suffixes like
m (minutes) and h (hours).
Edge-Control: downstream-ttl=60m
allow-unvalidated
The allow-unvalidated directive permits the edge server
to serve stale cached content without revalidating with
the origin first. This keeps content available during
origin outages or revalidation delays.
Edge-Control: allow-unvalidated
Example
A robots.txt response from a Meta property (Facebook, Instagram) with a one-day edge cache lifetime. The edge server caches the response for 86,400 seconds (24 hours) and serves cached copies for the duration. This is the most frequently observed Edge-Control pattern in production.
Edge-Control: max-age=86400
A CDN caching a JavaScript library for seven days at the
edge, with downstream caches receiving a 60-minute TTL.
The cache-maxage directive uses a day-based format,
and downstream-ttl caps intermediate cache freshness
at a shorter window.
Edge-Control: cache-maxage=7d downstream-ttl=60m
A streaming or personalized page bypassing CDN caching entirely. The edge server forwards every request to the origin without storing a copy.
Edge-Control: no-store
CDN-Cache-Control
Akamai recommends CDN-Cache-Control for new configurations. CDN-Cache-Control uses standard Cache-Control directive syntax but targets CDN edge nodes exclusively. Existing Edge-Control configurations continue to work.
Takeaway
The Edge-Control header provides Akamai-specific caching directives for edge servers, separate from browser-facing Cache-Control. Edge nodes consume and remove the header before forwarding the response to clients. For new Akamai configurations, Targeted Cache Control via CDN-Cache-Control is the recommended path.