Edgio Applications v4 and support for Node.js 16 are undergoing end-of-life (EOL). Read the Layer0 EOL announcement, the Node.js 16 EOL plan  or browse Edgio Applications v7 docs.
Edgio
Edgio

Response Headers

This guide describes the headers that Edgio injects into responses, making them visible to your client code. Note that the x-0-* headers namespace is reserved for Edgio internal use and setting them yourself, except where so noted, is unsupported. See Prohibited Headers for more information.

Reserved Response Headers

  • x-0-caching-status: Indicates cache status information. If the response was not cached or served from cache, then it will report the reason why it was not cached.
    Example:
    The following sample response header indicates that caching was explictly disabled for this request:
    x-0-caching-status: disabled
Learn more.
  • x-0-components: Indicates the version for each POP component that processed the request and the environment ID. This response header is primarily meant for internal use when troubleshooting issues.
  • x-0-hit-request-id: Indicates the request’s unique ID. This response header is only returned for cached responses.
  • x-0-request-id: Indicates the request’s unique ID.
  • x-0-status: Contains a comma-delimited list of HTTP status codes for each POP component that processed the request.
  • x-0-surrogate-key: Contains a space-delimited list of surrogate keys (cache tags).
    Learn more.
  • x-0-t: Contains time measurements for each Edgio component through which a request was routed. It also provides cache status information for edge and global POPs.
  • x-0-version: Describes the Edgio deployment.

x-0-status Response Header

The x-0-status response header contains an HTTP status code for each POP component that processed the request. This comma-delimited list is presented sequentially according to the order in which POP components processed the request.
Syntax: x-0-status: <POP Component 1>=<Status Code 1>[,<POP Component 2>=<Status Code 2>,<POP Component n>=<Status Code n>]
A POP component is identified through the following two abbreviations:
Standard Traffic Example: The following sample response header indicates that the following POP components returned a 200 OK: Edge POP’s HAProxy, Edge POP’s DPS, Global POP’s HAProxy, and Global POP’s DPS.
x-0-status: eh=200,ed=200,gh=200,gd=200
Serverless Compute Example: The following sample response header indicates that the following POP components returned a 200 OK: Edge POP’s HAProxy, Edge POP’s DPS, Global POP’s HAProxy, Global POP’s DPS, Serverless Compute (load balancer), and Serverless Compute (Lambda worker).
x-0-status: eh=200,ed=200,gh=200,gd=200,p=200,w=200

x-0-t Response Header

The x-0-t response header contains time measurements for each Edgio POP component through which a request was routed. It also provides cache status information for edge and global POPs. This data is presented sequentially according to the order in which POP components processed the request.
Learn how Edgio routes requests.
Syntax:
x-0-t: <Metric 1>=<Value 1>[,<Metric 2>=<Value 2>,<Metric n>=<Value n>]
Each metric is defined through a set of abbreviations. These abbreviations identify:
  • Who handled the request:
    • e: Edge POP
    • g: Global POP
    If a global POP is the closest POP to the client, then it will act as both an edge and global POP. However, it will be assigned the e abbrevation instead of g.
    For example, you may typically measure an origin server’s response time through gdf (Global POP’s DPS Fetch Time). However, if a global POP is the closest POP to the client, then you should use edf instead since Edgio will not return gdf.
    • p: Serverless Compute (load balancer)
    • w: Serverless Compute (Lambda worker)
  • The POP component that processed the request:
    • h: HAProxy (load balancer)
    • c: Varnish (cache)
    • d: Dynamic Proxy Service (DPS)
    • b: Billing
    • k: Kolben
  • The type of metric being measured:
    • c: This abbreviation represents either of the following metrics:
      • Cache status. Valid values are:
        • hit: The response was served from cache.
        • miss: The response was forwarded to the next hop in the route because a cached response with a valid time-to-live (TTL) was not found. This value, which may only be returned when cached or pass is inapplicable, typically indicates that the response contains a set-cookie header or its status code is 4xx or higher.
        • cached: The response was cached as a result of this request.
        • pass: The route corresponding to this request or cache-specific response headers prohibit caching.
        For example, gcc=miss identifies a cache miss on a global POP. A global POP forwards requests that result in cache misses to either an origin server or Serverless Compute.
      • Request count.
        For example, pc=1 indicates the number of requests generated by the Serverless Compute (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. Another example is wc=19 which indicates that a Serverless Compute (Lambda worker) was invoked 19 times by this request.
    • d: DNS lookup time in milliseconds.
      DPS uses DNS caching to accelerate requests. This means that DPS may frequently report a DNS lookup time of 0.
      For example, edd identifies the DNS lookup time as measured by an edge POP’s DPS.
    • f: Fetch time in milliseconds. This metric measures the amount of time between when a POP component forwards a request and when it receives a response.
      For example, gdf indicates the amount of time between when a global POP’s DPS forwarded a request to an origin server or Serverless Compute and when it started receiving a response.
    • g: Age in seconds.
      For example, wg=746940 indicates that the instance of the Serverless Compute (Lambda worker) that processed the request has been running for approximately 747 seconds.
    • l: Sum of time in milliseconds.
      For example, wl=30896 indicates the total processing time for all Serverless Compute (Lambda workers) for all requests is 30.8 seconds.
    • m: Memory usage in Megabytes.
      For example, wm=317 indicates that Serverless Compute (Lambda worker) used 317 Megabytes of memory for this request.
    • r: Route evaluation in milliseconds.
      For example, wr=1 indicates that Serverless Compute (Lambda worker) spent 1 millisecond evaluating the route through which this request will be processed.
    • t: Total time in milliseconds. This metric measures the amount of time between the moment when the request was received to when a response was sent to the client.
      For example, wbt indicates billed time as measured by a Serverless Compute load balancer. This measurement includes Serverless Compute workload time and time spent capturing Serverless Compute log data.
    • u: Upstream fetch time in milliseconds.
      For example, pu identifies the total time between when a Serverless Compute load balancer submitted a request defined within your application’s code (e.g., fetch) and when it received a response.

Exceptions

Most metrics follow the above convention. However, there are some metrics that use a different convention. Here are a few common exceptions to the above convention:
  • dgpop: Identifies the global POP to which an edge POP forwarded a request.
  • eh: Identifies the total time, in milliseconds, as measured by an edge POP’s HAProxy.
  • gh: Identifies the total time, in milliseconds, as measured by a global POP’s HAProxy.
  • wa: Indicates the transformRequest time, in milliseconds, as measured by a Serverless Compute (Lambda worker).
  • wp: Indicates the fetch or proxy time, in milliseconds, as measured by a Serverless Compute (Lambda worker).
  • wz: Indicates either:
    • transformResponse: If the route uses transformResponse, then this metric measures the transformResponse time in milliseconds.
    • Image Optimization: If the route contains an image optimization tag, such as Next Image or Nuxt nuxt-img, instead of transformResponse, then this metric measures processing time in milliseconds.

Sample x-0-t Response Headers

Sample response headers for both standard traffic and Serverless Compute are explained below.
Standard Traffic
The following sample x-0-t response header is for a request that was routed through an edge POP to a global POP:
x-0-t: eh=325,ect=322,ecc=cached,edt=316,edd=0,edf=316,dgpop=hef,gh=7,gct=5,gcc=hit
We will now examine each metric defined within the above sample response header:
ValueDescription
eh=325Indicates the total time from an edge POP’s HAProxy was 325 milliseconds.
ect=322Indicates the total time from an edge POP’s Varnish (cache) was 322 milliseconds.
ecc=cachedIndicates that the edge POP’s Varnish (cache) cached the response as a result of this request.
edt=316Indicates the total time from an edge POP’s DPS was 316 milliseconds.
edd=0Indicates the DNS lookup time for an edge POP’s DPS was 0 milliseconds. This typically means that DPS used DNS caching.
edf=316Indicates the fetch time from an edge POP’s DPS was 316 milliseconds.
dgpop=hefIndicates that the edge POP forwarded the request to the HEF global POP.
gh=7Indicates the total time from a global POP’s HAProxy was 7 milliseconds.
gct=5Indicates the total time from a global POP’s Varnish (cache) was 5 milliseconds.
gcc=hitIndicates that the global POP’s Varnish (cache) served the response from cache.
Serverless Compute
The following sample x-0-t response header is for a Serverless Compute request. A Serverless Compute request is routed through an edge POP, global POP, and then to our Serverless Compute service. This request flow ensures optimal performance by serving requests from cache whenever possible.
x-0-t: eh=1160,ect=1158,ecc=miss,edt=1152,edd=0,edf=1152,gh=869,gct=866,gcc=miss,gdt=853,gdd=0,gdf=853,pt=811,pc=1,pf=809,wbt=723,wm=317,wt=722,wc=19,wg=746940,wl=30896,wr=1,wp=705,wa=1,wz=1
We will now examine each metric defined within the above sample response header:
ValueDescription
eh=1160Indicates the total time from an edge POP’s HAProxy was 1160 milliseconds.
ect=1158Indicates the total time from an edge POP’s Varnish (cache) was 1158 milliseconds.
ecc=missIndicates a cache miss on the edge POP’s Varnish (cache). Requests that cannot be served from cached are forwarded to the global POP.
edt=1152Indicates the total time from an edge POP’s DPS was 1152 milliseconds.
edd=0Indicates the DNS lookup time for an edge POP’s DPS was 0 milliseconds. This typically means that DPS used DNS caching.
edf=1152Indicates the fetch time from an edge POP’s DPS was 1152 milliseconds.
gh=869Indicates the total time from a global POP’s HAProxy was 869 milliseconds.
gct=866Indicates the total time from a global POP’s Varnish (cache) was 866 milliseconds.
gcc=missIndicates that a cache miss on the global POP’s Varnish (cache). Requests that cannot be served from cached are forwarded to Serverless Compute.
gdt=853Indicates the total time from a global POP’s Varnish (cache) was 853 milliseconds.
gdd=0Indicates the DNS lookup time for a global POP’s DPS was 0 milliseconds. This typically means that DPS used DNS caching.
gdf=853Indicates the fetch time from a global POP’s DPS was 853 milliseconds.
pt=811Indicates the total time from a Serverless Compute (load balancer) was 811 milliseconds.
pc=1Indicates the request count for a Serverless Compute (load balancer) was 1.
pf=809Indicates the fetch time from a Serverless Compute (load balancer) was 809 milliseconds.
wbt=723Indicates that billed time for Serverless Compute was 723 milliseconds.
wm=317Indicates that memory usage for a Serverless Compute (Lambda worker) was 317 MB.
wt=722Indicates that the workload time for a Serverless Compute (Lambda worker) was 722 milliseconds.
wc=19Indicates that this instance of Serverless Compute was invoked 19 times.
wg=746940Indicates that this instance of Serverless Compute has been running for 747 seconds.
wl=30896Indicates that the total processing time for all Serverless Compute (Lambda Workers) for all requests is 30.8 seconds.
wr=1Indicates that Serverless Compute (Lambda worker) spent 1 millisecond evaluating the route through which this request will be processed.
wp=705Indicates the fetch or proxy time as measured by a Serverless Compute (Lambda worker) was 705 milliseconds.
wa=1Indicates the transformRequest time as measured by a Serverless Compute (Lambda worker) was 1 millisecond.
wz=1Indicates either a transformResponse time or processing time in milliseconds. Learn more.

x-0-Version Response Header

The x-0-version response header describes the latest Edgio deployment using the following syntax:
x-0-version: <Deployment #> <Package Version> <Environment Version> <Deployment Timestamp> <Compiler Version>
Definitions for the above variables are provided below.
  • <Deployment #>: Identifies a deployment by its version number.
  • <Package Version>: Indicates the Edgio package version.
  • <Environment Version>: Identifies an environment by its version number.
  • <Deployment Timestamp>: Indicates the date and time (UTC; 24-hour clock) at which your site was deployed.
    Syntax: YYYY-MM-DDThh:mm:ss.msZ
  • <Compiler Version>: Indicates the Edgio compiler version through which your site was compiled.
Example:
x-0-version: 23 4.17.1 3 2022-09-15T12:54:14.721Z 1.5.0

Server Timing Response Header

Edgio adds the following values to the standard server-timing response header:
  • layer0-cache: <Cache Status>: Valid cache statuses are:
    • HIT-L1: Indicates that the request was served from an edge POP’s cache.
    • HIT-L2: Indicates that the request was served from a global POP’s cache.
    • MISS: Indicates that the request was not served from cache.
  • country: <Country Code>: Indicates the two-letter code for the country from which the request was sent.
  • xrj: <Route>: Indicates the route that Edgio mapped to the request. This route is serialized into JSON.

Serverless Compute - Cold Start Timing

To calculate the Serverless cold start timing you must take the difference between pf and wt in the x-0-t header. wt is time taken for the lambda to execute after it has started, this is can be read as the time is takes the project code to execute. If that seems large, evaluate the code within your project to see why this might be. To track timings for a function, it is possible to add specific code to do that.
Based on the example above, that would be 809 (pf) - 722 (wt) = 87ms.