Introducing Edgio Applications v7Find out what's new.
Edgio
Edgio

Response

Each request for your content will generate a response from a server. This response consists of:

Protocol and Version

Identifies the network protocol and version (e.g., HTTP/1.1) used to transmit the response to the client. This protocol and version typically matches the one defined in the request. If an invalid protocol or version was requested, then the response will return a 505 HTTP Version Not Supported.

Status Codes

HTTP status codes are how the web signals errors and other states from the server to the web browser. If there is an error from your backend website, the error is simply forwarded by Edgio to the browser.

Edgio exclusive status codes

If the error is generated in Edgio itself, the platform generates a 53x or 54x HTTP status code:
CODENAMEDESCRIPTION
530Internal Edgio ErrorUnexpected error in Edgio. Please contact support immediately.
531Project Upstream Connection ErrorYour project failed to establish an upstream connection. This is different from 536 where your project timed out waiting for a response from the upstream. Common causes are the upstream host you specified in your project is incorrect, the DNS entry you defined points to the wrong server, your servers are not responding, or you need to add the Edgio IP addresses to your allowlist. (Contact your operations team and ask them to add the IP addresses in Allowlisting to your server’s IP allowlist.)
532Project Response Too LargeYour project returned a response size greater than the allowed 6MB.
533Project Upstream TLS ErrorThe was an error negotiating a secure TLS connection with the upstream. Common causes are the host name provided does not match the name in the upstream TLS certificate, or the upstream TLS certificate has expired.
534Project ErrorYour project’s serverless code has failed unexpectedly or has issued a malformed response. Use server logs to debug.
535Unknown ProjectThe HTTP header host is missing or does not match any Edgio deployment. Check your requesting URL and your project config.
536Project HTTP Response TimeoutEdgio did not receive an HTTP response from the upstream. Common causes are the upstream dropped the connection prematurely, the upstream application threw an exception, and the upstream took too long to respond.
537Project DNS Resolution ErrorFailed to resolve the host name through DNS, which might indicate a problem with your DNS provider or incorrectly configured domain name.
538Project Request LoopThe Edgio project exceeded the maximum level (3) of nested Edgio requests. “Nested” means an Edgio site is the upstream of itself or of another Edgio site.
539Project TimeoutThe 539 status code is primarily caused by timeouts, but can also be caused by lack of allow lists (white lists) configured on your backend server. Timeouts: Your project’s serverless code did not respond on time, either due to slow or blocking upstream or to badly handled asynchronous requests in code (e.g. missing await or call to callback). Troubleshooting: You can view the timings and status codes of the components in the stack in the x-edg-t header Use server logs and performance profiling to debug. You can also debug using information in Troubleshooting 539 Status Codes, which includes information about detecting allow list errors.
540Out of MemoryYour project’s serverless code caused an out-of-memory situation. Use server logs to debug and lower the memory use.
541Edgio Out of WorkersThe traffic was so high that the request could not be scheduled for processing within the scheduling timeout. Please contact support to upgrade your account.
542Project Header OverflowThe Edgio project’s request or response had too many HTTP headers. See limits
543Global Upstream TimeoutThe request failed to propagate between Edgio edge and the global POP. Please contact support.
544Invalid Host HeaderThe Edgio received a value in host header that is not a valid domain name.
545Edgio Component Not ReadyAn unprepared Edgio component received traffic. Please contact support immediately.
546Edgio Global POP TLS ErrorThe was an error negotiating a secure TLS connection with the Edgio global POP. Please contact support immediately.
547Edgio Global POP No HTTP ResponseEdgio did not receive an HTTP response from the global POP. Please contact support immediately.
548Edgio Global POP DNS Resolution ErrorEdgio failed to resolve the global POP’s host name through DNS. Please contact support immediately.
Obviously, your project can set status codes of their own, which may sometimes match codes above. We encourage you to avoid setting your own status code so as to lower troubleshooting overhead and other issues.

Standard status codes used by Edgio itself

Edgio also issues these standard response codes:
CODENAMEDESCRIPTION
400Bad RequestThe URL is too long or the request headers are too large. See limits
404Not FoundThe server cannot find the requested resource. This usually occurs when the browser requests a page that your app does not have. A 404 will also occur when a request does not match any of the routes in your Edgio router. Learn more..
412Precondition FailedThis code is returned when the query string parameter edgio_prefetch equals 1 and the content was not found in the edge cache.

Response Headers

Response headers that start with x-edg-* or x-ec- are reserved for use by Edgio.
The response headers generated for content requested through our CDN describe the response provided by an edge server. By default, our edge servers will include:
  • 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

Common response headers are described below.
  • 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:
      Response header value: 111 - "Revalidation Failed", 110 - "Response is stale"

Edgio-Specific Headers

Edgio-specific headers are described below.
  • 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 cache response headers provide additional information about the cache policy applied to the requested asset. 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 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-check-cacheable,x-ec-cache-key,x-ec-cache-state
Valid values for the x-ec-debug request header are provided below.

Cache Status Code Information

The following response headers identify a server and how it handled the response:
  • 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)
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 reports or raw log data.
  • POP: Indicates the three-letter abbreviation for the POP that handled the 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.
Syntax: x-ec-check-cacheable: <CACHEABLE>
Example: x-ec-check-cacheable: YES
The term CACHEABLE indicates whether the requested content could have been cached. Valid values for this term are:
  • 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

The x-ec-cache-key response header indicates the cache key associated with the requested content. A cache key 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 cache key.
Learn more about cache keys.

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.
Syntax: x-ec-cache-state: max-age=<MAX-AGE SECONDS> (<MAX-AGE TIME PERIOD>); cache-ts=<UNIX TIME> (<ddd>, <dd MMM yyyy HH:mm:ss> GMT); cache-age=<CACHE-AGE SECONDS> (<CACHE-AGE TIME PERIOD); remaining-ttl=<REMAINING TTL (SECONDS)> (<REMAINING TTL TIME PERIOD>; expires-delta=<EXPIRES SECONDS>
Example: x-ec-cache-state: max-age=604800 (7d); cache-ts=1341802519 (Mon, 09 Jul 2012 02:55:19 GMT); cache-age=0 (0s); remaining-ttl=604800 (7d); expires-delta=none
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 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

The following abbreviations are used for time units:
  • s: Seconds
  • h: Hour(s)
  • d: Day(s)
  • m: Month(s)
  • y: Year(s)

Serverless Compute - Cold Start Timing

To calculate the Serverless cold start timing you must take the difference between pf and wt in the x-edg-t header. wt is time taken for the Serverless Compute worker 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.

Response Body

Contains the data provided in response to the request.
For example, the response body for a GET request for a text file might look similar to the following:
1Hello World!