Response

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

Protocol and Version #

Status Codes #

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: This 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-aws-region: Indicates the AWS region from which a request to the Edgio cloud was served.
• x-edg-components: Contains Edgio cloud information that is primarily meant for internal use when troubleshooting issues.
• x-edg-mr: Identifies each rule that was applied to a request.
  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-platform-aws-account: Identifies the AWS account corresponding to the cloud worker that processed a request.
• x-edg-status: Contains a comma-delimited list of HTTP status codes for each cloud component that processed the request.
  • p: Cloud load balancer
  • w: Cloud worker
  Example: x-edg-status: p=200,w=200
• x-edg-surrogate-key: Contains a space-delimited list of surrogate keys (cache tags).
  Learn more.
• x-edg-t: Contains time measurements and cache status information for Edgio cloud requests (Edgio Sites and Cloud Functions).
• 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.
  Syntax: x-ec-debug: <DEBUG CACHE HEADER>[,<DEBUG CACHE HEADER>,<DEBUG CACHE HEADER>]
  Example: x-ec-debug: x-ec-cache,x-ec-cache-remote,x-ec-check-cacheable,x-ec-cache-key,x-ec-cache-state
  Valid values for the x-ec-debug request header are provided below.
  • 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
  Once you have enabled the Debug Header feature, use the Edgio Developer Tools Chrome extension to automatically add all debug cache response headers to traffic served by Edgio. View these response headers by inspecting network activity through Chrome DevTools.

  Alternatively, if you are using the latest version of the Edgio CLI (v7.0.22+), then edgio curl will also automatically add all debug cache headers to the response.

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)

• CACHE STATUS CODE: Indicates how the requested content was handled by the CDN. This is represented through a cache status code.
• 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)

x-edg-t Response Header #

• pt: Cloud load balancer time. Indicates the total time, in milliseconds, it took to process the cloud request. This metric measures the time between when the cloud load balancer receives the request and when it sends a response to the client.
• pc: Cloud load balancer counter. Indicates the number of requests generated by the cloud load balancer. A value greater than 1 indicates that the load balancer had to scale the request by adding it to a queue and then resubmitting it. This occurs due to low available compute capacity.
• pf: Cloud load balancer fetch time. Indicates the total time, in milliseconds, it took to fetch a response from a cloud worker. Specifically, it measures the amount of time between when the cloud load balancer forwards a request to a cloud worker and when it receives a response.
• wbt: Cloud worker billed time. Indicates the total billed time in milliseconds. This measurement may be higher than wt, since it includes cloud workload time and time spent capturing cloud log data.
• wbm: Cloud worker billed memory. Indicates billed memory usage in Megabytes. This metric measures memory allocated to the cloud worker.
• wm: Cloud worker memory. Indicates actual cloud worker memory usage in Megabytes.
• wt: Cloud worker time. Indicates the total time, in milliseconds, it took for the cloud worker to generate a response.
• wc: Cloud worker count. Indicates the number of times that a cloud worker was invoked for this request.
• wg: Cloud worker age. Indicates the amount of time, in milliseconds, that the instance of the cloud worker that processed the request has been running.
• wl: Cloud worker lifetime. Indicates the total processing time, in milliseconds, for all cloud workers for all requests.

Cloud - Cold Start Timing #

Response Body #

1Hello World!