Response

• Protocol and version
• Status code
• Response headers
• Response body

Protocol and Version #

Status Codes #

Edgio exclusive status codes #

Standard status codes used by Edgio itself #

Response Headers #

• Response headers generated by the origin server.
  Example: The Last-Modified and ETag response headers determine whether our edge servers will be able to revalidate stale content.
• Response headers that describe the response (i.e., date, size, and content type).
• Response headers that define or describe the requested content’s cache policy.
• Information that identifies the edge server that served the response.

Common Response Headers #

• Accept-Ranges: Indicates whether a server can accept range requests.
  Default value: bytes
  The default value indicates that our servers can accept byte-range requests.
• Cache-Control: max-age: Indicates the maximum length of time that a request is considered fresh. An edge server can serve fresh content directly from cache without having to perform a revalidation with the origin server.
• Content-Encoding: Indicates that a compressed version of the requested content was served to the client. This response header indicates the asset’s compression type (e.g., gzip, deflate, bzip2, etc.).
• Content-Length: Indicates the size of the response body in octets.
• Content-Type: Indicates the media type (aka content type) for the response body.
• Date: Indicates the date and time (GMT) on which the edge server returned a response.
• Etag: Indicates the entity tag (ETag) for the requested content. This ETag allows our edge servers to revalidate stale content. In other words, our edge servers will use ETag when checking with the origin server to see if there is a newer version of the requested content.
• Expires: Indicates the date and time (GMT) at which the response will be considered stale. By default, our edge servers must revalidate requests for stale content.
• Last-Modified: Indicates the date and time (GMT) at which the requested content was last updated.
• Server: Provides information about the server that fulfilled the request.
  • Origin Server: If an origin server provided a response for a cache miss that includes the Server response header, then our edge servers will forward it to the client. If it is missing from the response, then the CDN will define this header as indicated below.
  • CDN: The following syntax applies for responses served from cache or when the Server response header is missing from the response provided by an origin server: ECAcc (<POP>/<ID>)
    Definitions for the above terms are provided below.
    • POP: Indicates the POP that handled the request.
    • ID: This field is for internal use only.
    Example: server: ECAcc (lac/55D2)
• Server-Timing: Edgio returns this response header when the Server-Timing Header feature has been enabled. The Server-Timing response header contains cache status information and information about the POP that served the response.
  Syntax: server-timing: edgio_cache;desc=<CACHE STATUS CODE>,edgio_pop;desc=<POP>,edgio_country;desc=<COUNTRY>
  Example: server-timing: edgio_cache;desc=TCP_HIT,edgio_pop;desc=lac,edgio_country;desc=US
  Definitions for the above terms are provided below.
  • CACHE STATUS CODE: Indicates the cache status code for the response served to the client.
  • POP: Indicates the POP that served the response.
  • COUNTRY: Indicates the two-letter code for the POP’s country.
• Vary: Identifies the variant that defines whether cached content can be served for future requests.
  Key information:
  • Our network only supports a single variant called Accept-Encoding. This value indicates that the Accept-Encoding request header determines whether cached content will be served.
  • By default, our edge servers only return this header when the requested content was previously cached.
  • The Accept-Encoding request header identifies the type of compression requested by the client. An edge server may deliver the requested content immediately if the cached asset matches the requested compression method.
• Warning: This response header is only returned when a stale response is served to the client. A stale response is typically served under the following conditions:
  • The Stale While Revalidate feature was applied to the request.
    Response header value: 110 - "Response is stale"
  • Revalidation failed and either of the following conditions is true:
    • The origin server returned a 5xx response and the Stale on Error feature was applied to the request.
    • The origin server is unresponsive and the stale window, as defined by the Revalidate After Origin Unavailable feature, is active.
    Response header value: 111 - "Revalidation Failed", 110 - "Response is stale"

Edgio-Specific Headers #

• x-cache: HIT: Indicates that a cached version of the requested content was served directly to the client by an edge server.
  Example: x-cache: HIT
• x-ec-debug: Contains the requested debug cache metadata when the Debug Header feature has been enabled. Learn more.
• x-edg-hit-request-id: For responses served from cache, this header indicates the unique ID of the request that was cached on our CDN.
• x-edg-mr: Indicates one or more matched route(s).
  Syntax: x-edg-mr: <ENVIRONMENT #>:<RULE #>[;<ENVIRONMENT #>:<RULE #>;<ENVIRONMENT #>:<RULE #>]
  Example: x-edg-mr: 16:0;16:1;
  Definitions for the above terms are provided below.
  • ENVIRONMENT #: Indicates the environment’s version number.
  • RULE #: Indicates the index number of the rule that was applied to the request.
  Click the Show Rule Numbers link at the top of the Rules page to display a number next to each rule.
  CDN-as-Code: Configurations deployed through the Edgio CLI are converted into rules. You may view these rules through the Rules page.
• x-edg-p: Returns 1 when the client’s request includes an edgio_prefetch query string parameter. This parameter indicates that the client is requesting Predictive Prefetching.
  Example: x-edg-p: 1
• x-edg-request-id: Indicates the request’s unique ID.
• x-edg-surrogate-key: Contains a space-delimited list of surrogate keys (cache tags).
  Learn more.
• x-edg-version: Indicates basic information for your current deployment.
  Syntax: x-edg-version: <DEPLOYMENT> <ENVIRONMENT VERSION> <INTERNAL> NA <DEPLOYMENT TIMESTAMP> <ENVIRONMENT ID>
  Example: x-edg-version: 16 16 19 NA 2023-04-02T22:52:30Z ed922fee-185c-427d-8949-83d135108aab
  Definitions for the above terms are provided below.
  • DEPLOYMENT: Identifies a deployment by its version number.
  • ENVIRONMENT VERSION: Indicates the environment’s version number.
  • INTERNAL: Reserved for future use.
  • DEPLOYMENT TIMESTAMP: Indicates the date and time (UTC; 24-hour clock) at which your site was deployed.
    Syntax: YYYY-MM-DDThh:mm:ss.msZ
  • ENVIRONMENT ID: Identifies an environment by its system-defined ID.

Requesting Debug Cache Information #

• The Debug Header feature has been enabled on the desired request.
• The request sets a x-ec-debug header to the set of debug cache headers that will be included in the response.

• 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 #

• x-ec-cache: This response header is reported whenever content is routed through the CDN. It identifies the edge server that fulfilled the request.
  Syntax: x-ec-cache: <CACHE STATUS CODE> from ECAcc (<POP>/<ID>)
  Example: x-ec-cache: TCP_HIT from ECAcc (lga/0FE8)
• x-ec-cache-remote: This response header is only reported when the requested content was cached on an origin shield server.
  Syntax: x-ec-cache: <CACHE STATUS CODE> from ECAcc (<POP>/<ID>)
  Example: x-ec-cache-remote: TCP_HIT from ECAcc (dca/EF00)

• 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 reports or raw log data.
• POP: Indicates the three-letter abbreviation for the POP that handled the request.

Cacheable Response Header #

• 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, you may create a rule that prevents the response from being cached by enabling the Bypass Cache feature.
  • 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.

Cache Key Response Header #

Cache State Response Header #

• 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 to the approximate equivalent of a larger unit (e.g., days).
• 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.
• 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).
• 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 #

• s: Seconds
• h: Hour(s)
• d: Day(s)
• m: Month(s)
• y: Year(s)

Serverless Compute - Cold Start Timing #

Response Body #

1Hello World!