Debug Cache Response Headers

The debug cache response headers provide additional information about the cache policy applied to the requested asset.

Usage

The response sent from our edge servers to a user will only include debug cache response headers when the following conditions are true:

Requesting Debug Cache Information

Request debug cache response headers by setting the X-EC-Debug request header to the desired debug cache response headers:

Syntax:

X-EC-Debug: Debug Cache Header 1,Debug Cache Header 2,Debug Cache Header N

Example:

X-EC-Debug: x-ec-cache,x-ec-check-cacheable,x-ec-cache-key,x-ec-cache-state

Valid debug cache header values are provided below.

Request Header Type

x-ec-cache

Cache Status Code

x-ec-cache-remote

Cache Status Code

x-ec-check-cacheable

Cacheable

x-ec-cache-key

Cache-Key

x-ec-cache-state

Cache State

Cache Status Code Information

The following response headers identify a server and how it handled the response:

Response Header Description

x-ec-cache

This response header is reported whenever content is routed through the CDN. It identifies the edge server that fulfilled the request.

x-ec-cache-remote

This response header is only reported when the requested content was cached on an origin shield server or ADN Gateway server.

Response Header Format

The format through which the x-ec-cache and x-ec-cache-remote response headers will report cache status code information is indicated below.

The terms used in the above response header syntax are defined below:

Sample Response Headers

The following sample response headers provide cache status code information for a sample request.

x-ec-cache: TCP_HIT from ECD (lga/0FE8)
x-ec-cache-remote: TCP_HIT from ECD (dca/EF00)

Cacheable Response Header

The x-ec-check-cacheable response header indicates whether the requested content could have been cached.

This response header does not indicate whether caching took place. Rather, it simply indicates whether the request was eligible for caching.

Response Header Format

The format through which the x-ec-check-cacheable response header will report whether a request could have been cached is indicated below.

x-ec-check-cacheable: Cacheable

The term used in the above response header syntax is defined below:

Value Description

YES

Indicates that the requested content was eligible for caching.

NO

Indicates that the requested content was ineligible for caching. This may be due to one of the following reasons:

  • Customer-Specific Configuration: A configuration specific to your account can prevent our edge servers from caching an asset. For example, Rules Engine can prevent an asset from being cached by enabling the Bypass Cache feature for qualifying requests.
  • Cache Response Headers: The requested asset's Cache-Control and Expires headers can prevent our edge servers from caching it.

UNKNOWN

Indicates that our servers were unable to assess whether the requested asset was cacheable. This typically occurs when the request is denied due to Token-Based Authentication.

Sample Response Header

The following sample response header indicates whether the requested content could have been cached.

x-ec-check-cacheable: YES

Cache-Key Response Header

The x-ec-cache-key response header indicates the physical cache-key associated with the requested content. A physical cache-key consists of a path that identifies an asset for the purposes of caching. In other words, our servers will check for a cached version of an asset according to its path as defined by its cache-key.

This physical cache-key starts with a double forward slash (i.e., //) followed by the protocol used to request the content (i.e., http or https). This protocol is followed by the relative path to the requested asset. This relative path starts with the content access point (e.g., /000001/).

By default, HTTP platforms are configured to use "standard-cache." This means that query strings are ignored by the caching mechanism. This type of configuration will prevent the cache-key from including query string data.

If a query string is recorded in the cache-key, it will be converted to its hash equivalent. After which, it will be inserted between the name of the requested asset and its file extension (e.g., assetHashValue.html).

Response Header Format

The format through which the x-ec-cache-key response header will report physical cache-key information is indicated below.

Sample Response Header

The following sample response header indicates the physical cache-key for the requested content.

x-ec-cache-key: //http/800001/origin/images/foo.jpg

Cache State Response Header

The x-ec-cache-state response header indicates the cache state of the requested content at the time it was requested.

Response Header Format

The format through which the x-ec-cache-state response header reports cache state information is indicated below.

x-ec-cache-state: max-age=max-age Seconds (max-age Time Period); cache-ts=Unix Time (ddd, dd MMM yyyy HH:mm:ss GMT); cache-age=cache-age Seconds (cache-age Time Period); remaining-ttl=Remaining TTL Seconds (Remaining TTL Time Period); expires-delta=Expires Seconds

The terms used in the above response header syntax are defined below:

Time Unit Abbreviations

The following abbreviations are used for time units.

Abbreviation Description

s

Seconds

h

Hour(s)

d

Day(s)

m

Month(s)

y

Year(s)

Sample Response Header

The following sample response header indicates the cache state of the requested content at the time that it was requested.

x-ec-cache-state: max-age=604800 (7d); cache-ts=1341802519 (Mon, 09 Jul 2012 02:55:19 GMT); cache-age=0 (0s); remaining-ttl=604800 (7d); expires-delta=none