Request

Learn about reserved request headers and how requests are routed through our service.

Request Flow #

Edgio routes requests according to traffic type and whether the request is eligible for caching.

• Standard Traffic: By default, requests are routed to an origin server through an edge POP (L1) and a global POP (L2). This behavior maximizes cache hits and shields your origin servers by funneling all cache misses through a global POP.

  

  Edgio is optimized for performance and therefore always routes requests to the closest POP. If a global POP is the closest POP to a client, then Edgio will treat it as an edge and global POP. This means that cache misses on that POP are sent directly to the origin server as illustrated below.

  

  Another performance optimization occurs for routes on which you have disabled caching. Edgio bypassses global POPs for those requests and sends them directly to your origin servers.

  

• Serverless Compute: Edgio routes Serverless Compute requests similar to standard traffic. However, cache misses are forwarded to a Serverless Compute load balancer which distributes requests to a Serverless Compute worker.

  

  Edgio also optimizes Serverless Compute routes on which you have disabled caching. Edgio bypassses global POPs for those requests and sends them directly to a Serverless Compute load balancer.

  

POP Components #

All POPs have the following components:

• HAProxy: This component load balances requests to Varnish.
• Varnish: This component is a web application accelerator that is responsible for cache management.
• Dynamic Proxy Service (DPS): This component forwards requests from Varnish to an origin server.

Requests are routed through the above components in the following order:

HAProxy -> Varnish -> DPS

If a request is routed to an origin server through both an edge and global POP, then it will be routed through the above components twice:

Client -> Edge POP (HAProxy -> Varnish -> DPS) -> Global POP (HAProxy -> Varnish -> DPS) -> Origin Server

Reserved Request Headers #

Edgio injects headers into requests making them visible to your server code.

General headers #

• x-request-id: unique request ID on Edgio which may optionally be provided by you when issuing the requests to Edgio
• x-0-client-ip: the client IP address from which the request to Edgio edge components originated; cannot be used for user agent IP identification when Edgio is behind another CDN).
• x-0-destination: the routing destination as determined by traffic splitting rules if any; the name of the destinations are taken from Edgio router code and if not specified then default is default
• x-0-original-qs: contains the original query string if custom caching rules exclude query strings for the matching route; otherwise not set
• x-0-protocol: the protocol on which the connection to your site has been established; it can either be https or http; see more details here

User agent headers #

User agent headers are headers that Edgio derives by analyzing the received user-agent request header.

• x-0-device: device type which can be smartphone, tablet, mobile (feature phones) or desktop
• x-0-vendor: vendor of the device which can be apple, android or generic
• x-0-device-is-bot: Indicates whether the request’s user agent matches the user agent for a known bot. Returns 1 for known bots and 0 for all other requests.
• x-0-browser: browser type which can be chrome, safari, firefox, opera, edge, msie or generic

These values are provided as best effort as user agent, especially adversarial ones, can control the values by which we determine the values above.

Geolocation headers #

Geolocation headers contain the geographical information about the provenance of the request. They are based on the IP of the actual request or, if overriding need is presented, on the content of x-0-client-ip request header.

• x-0-geo-country-code: the ISO 3166 two letter code for the country from which the request originated. See the Alpha-2 code column in the list of ISO 3166 country codes for reference.
• x-0-geo-state-code: the two letter state code from which the request originated
• x-0-geo-city: the name of the city from which the request originated
• x-0-geo-postal-code: the ZIP or postal code from which the request originated
• x-0-geo-latitude: the geographical latitude from which the request originated
• x-0-geo-longitude: the geographical longitude from which the request originated
• x-0-geo-asn: the autonomous system number of the network operator from which the request originated

These values are provided as a best effort. Edgio cannot guarantee the accuracy of geolocation based on the client’s IP address. See also geolocation behind third-party CDNs.

Static prerendering headers #

• x-0-preload: Will be “1” if the request originated from Static Prerendering. Otherwise this header will not be present.