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.
• Nel: Indicates Edgio’s Network Error Logging (NEL) policy. This policy instructs the client to generate a report for each attempt to connect to our network.
  Review NEL data from within Edge Insights through the NEL data source.
  Example:

  1{
  2    "report_to": "default",
  3    "max_age": 43200,
  4    "include_subdomains": true,
  5    "failure_fraction": 1.0,
  6    "success_fraction": 0.001
  7}

• Report-To: Instructs the client on how to submit NEL reports.
  Example:

  1{
  2    "group": "default",
  3    "max_age": 1800,
  4    "include_subdomains": true,
  5    "endpoints": [{
  6            "url": "https://report.edgecast.com/nel/v0?envid=12345678-90ab-cdef-ghij-klmnopqrstuv&pop=lac"
  7        }
  8    ]
  9}

• 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-ec-proxy-error: Returns one of the following codes when an error occurs:

  Code	Description
  0	No or unknown error.
  1	Unexpected error due to a failed assertion.
  2	The origin server responded with an invalid HTTP header. Check the headers included in the response.
  3	The origin server prematurely closed the connection.
  4	Failed to encode the request.
  5	Failed to connect to the origin server. Troubleshoot.
  6	The client sent an invalid request header. Check the headers included in the request.
  7	Too many internal redirects.
  8	The client sent an invalid request (hotfile).
  9	The origin server did not respond. Check your web server’s availability.
  10	The origin server responded with an invalid response header. Check the headers included in the response.
  11	Failed to establish a TLS connection with the origin server. Troubleshoot.
  12	Failed to validate the TLS certificate. Troubleshoot.
  13	The origin server did not respond before the connection timed out. Check your web server’s availability.
  14	The origin request backlog is full.
  15	The origin server responded, but the connection timed out before it could be read.
  16	Failed to decode the response from the origin server.
  17	The origin server responded without including at least one header. Check the origin server’s response.
  18	The origin server responded, but the connection timed out before the payload could be read.
  19	Detected a proxy request loop.
  20	A timeout occurred before establishing a connection to the origin server. Check your web server’s availability.
  21	Failed connection due to a blacklisted origin server.
  22	Failed to decode the response from the origin server.
  23	The origin server is unavailable. Check your web server’s availability.

• 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
  • h: Cloud worker handler
  • s: Cloud worker server
  Examples:
  x-edg-status: p=200,w=200
  x-edg-status: p=542,h=542,s=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> <Edgio PACKAGE VERSION> <DEPLOYMENT TIMESTAMP> <ENVIRONMENT ID>
  Example: x-edg-version: 16 16 19 7.13.2 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.
  • Edgio PACKAGE VERSION: Indicates the version of the @edgio/core package for deployments performed through the CLI. Returns NA for deployments performed through the Edgio Console.
  • 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.

• hid: Cloud worker handler ID. The unique ID for the instance of the cloud worker handler that processed the request. The cloud worker handler component is responsible for supervising a cloud worker server instance, proxying the request to the server, and managing resources. This ID is same across all requests served by the same cloud worker. The number of cloud workers scales up and down based on traffic load.
• hlt: Cloud worker handler lifetime. The total time, in milliseconds, that this instance of the cloud worker handler existed.
• hrc: Cloud worker handler requests count. The number of requests that this instance of the cloud worker handler processed.
• hec: Cloud worker handler errors count. The number of errors, such as 540 Edgio Out of Resources or 549 Edgio Project Crashed, encountered by this instance of the cloud worker handler.
• hrss: Cloud worker handler resident set size. The amount of memory, in MiB, occupied by the code segment, heap, and stack of this instance of the cloud worker handler.
• ht: Cloud worker handler time. The total time, in milliseconds, it took this instance of the cloud worker handler to process the request (i.e., receive the request, proxy the request, fetch the response, and sending the response back to client).
• hcs: Cloud worker handler cold start. Returns true when this instance of the cloud worker handler was initiated by this request. Otherwise, returns false.
• hcst: Cloud worker handler cold start time. Returns the value of the ht metric as measured by the request at which the hcs metric was set to true.
• sid: Cloud worker server ID. The unique ID for the instance of the cloud worker server that processed the request.
  The cloud worker server component is responsible for importing your project code, starting your app (e.g., Next.js) and executing your compute functions. This ID is updated whenever your project is restarted due to a fatal error.
• slt: Cloud worker server lifetime. The total time, in milliseconds, this instance of the cloud worker server existed.
• src: Cloud worker server requests count. The number of requests processed by this instance of the cloud worker server. This value should match the value for the hrc metric unless your project was restarted due to a fatal error.
• sec: Cloud worker server errors count. The number of errors, such as 534 Edgio Project Error, encountered by this instance of the cloud worker server. .
• srss: Cloud worker server resident set size. The amount of memory, in MiB, occupied by the code segment, heap, and stack of this instance of the cloud worker server and your application.
• st: Cloud worker server time. The total time, in milliseconds, it took this instance of the cloud worker server to process the request (i.e., receive the request and then sending the response back to a cloud worker handler). For example, if you have a Next.js application, this metric measures the time it took the Next.js server to return a response.
• scs: Cloud worker server cold start. Returns true when this instance of the cloud worker server was initiated by this request. Otherwise, returns false.
• scst: Cloud worker server cold start time. Returns the value of the st metric as measured by the request at which the scs metric was set to true.
• srt: Cloud worker server ready time. The time, in milliseconds, it took for this instance of a cloud worker server to perform a cold start (i.e., the time from which this instance was spawned to to the moment it was ready to process requests).
• art: Application ready time. The time, in milliseconds, it took to import your application code and start your app (e.g., Next.js) after a cloud worker server cold start.

Cloud - Cold Start Timing #

Response Body #

1Hello World!