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:

• The Debug Cache Response Headers feature has been enabled on the desired request.
• The request defines the set of debug cache response headers that will be included in the response.

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:

Example:

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:

• Status Code: Indicates how the requested content was handled by the CDN. This is represented through a cache status code.

  The TCP_DENIED status code may be reported instead of NONE when an unauthorized request is denied due to Token-Based Authentication. However, the NONE status code will continue to be used when viewing Cache Status reports or raw log data.

• Platform: Indicates the platform on which the content was requested. The following codes are valid for this field:

  Code	Platform
  ECAcc	HTTP Large
  ECS	HTTP Small
  ECD	Application Delivery Network (ADN)

• POP: Indicates the POP that handled the request.

  View a list of POPs.

Sample Response Headers

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

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.

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

• Cacheable: Indicates whether the requested content could have been cached. Valid values for this term are:

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.

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.

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.

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

• max-age Seconds: Indicates the max-age (in seconds) as defined by the requested content's Cache-Control headers.

• max-age Time Period: Converts the max-age value (i.e., MASeconds) to the approximate equivalent of a larger unit (e.g., days).

  View time unit abbreviations.

• Unix Time: Indicates the cache timestamp of the requested content in Unix time (a.k.a. POSIX time or Unix epoch). The cache timestamp indicates the starting date/time from which an asset's TTL will be calculated.
  If the origin server does not utilize a third-party HTTP caching server or if that server does not return the Age response header, then the cache timestamp will always be the date/time when the asset was retrieved or revalidated. Otherwise, our edge servers will use the Age field to calculate the asset's TTL as follows:
  Retrieval/RevalidateDateTime - Age
• ddd, dd MMM yyyy HH:mm:ss GMT: Indicates the cache timestamp of the requested content. For more information, please see the UnixTime term above.
• cache-age Seconds: Indicates the number of seconds that have elapsed since the cache timestamp.
• Remaining TTL Seconds: Indicates the number of seconds remaining for which the cached content will be considered fresh. This value is calculated as indicated below.
  Remaining TTL Seconds = max-age - cache age

• Remaining TTL Time Period: Converts the remaining TTL value (i.e., Remaining TTL Seconds) to the approximate equivalent of a larger unit (e.g., days).

  View time unit abbreviations.

• Expires Seconds: Indicates the number of seconds remaining before the date/time specified in the Expires response header. If the Expires response header was not included in the response, then this term will report none.

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.

Edgecast CDN