You are reading Edgio v5 docs. Check out our latest docs for Edgio v7.
Edgio
Edgio

Third-Party CDNs

Edgio is designed and built to be the component of your site to which your users will directly connect to from their devices. Such components are colloquially known as “edge components”. But sometimes you may prefer to run Edgio behind a third-party CDN due to a pre-existing contract. Edgio fully supports this use case but it’s important to call out some common pitfalls with this kind of network topology.

HTTP traffic protocol

In order for Edgio to correctly determine the HTTP protocol (HTTP or HTTPS) used by the user agent, the third-party party CDN must use the same protocol that the user agent used. Thus, if the user agent has connected with HTTPS, the request passed to Edgio must also be HTTPS, otherwise a security hole has been created, ripe for the man-in-the-middle attack. Conversely, if the user agent connected with HTTP, the request passed to Edgio must also be HTTP so that the router rules that depend on the protocol continue to work correctly.

Redirects

By default, Edgio automatically redirects all HTTP traffic to HTTPS by issuing a 301 Moved Permanently redirect response. That redirect relies on the value of the host request header in order to form the value of the location response header (e.g., a host header value of docs.edg.io will result in a location value of https://docs.edg.io). When a third-party CDN is in front of Edgio, the host header may not be the public-facing domain but rather a domain to which the third-party CDN is routing traffic. In that case, the location header will have an incorrect value leading to an “escape” of the site from the public-facing domain to the private domain hosted on Edgio.

The same issue may affect all the custom redirects issued from Edgio using the redirect router function or when leveraging the environment redirects feature.

There are two major techniques to solve these problems:

  1. Configuring the third-party CDN to rewrite the location header whenever it sees such a response from Edgio.
  2. Configuring Edgio to serve the traffic on the same public facing domain and configuring the third-party CDN to send the traffic to Edgio edge IPs with the public facing domain in the host header.

A/B Testing

Edgio offers fully featured A/B testing. When Edgio is running behind another CDN, the CDN must be configured in a very specific way in order for A/B testing to work:

  1. Third-party CDN must be configured to not cache anything.
  2. The CDN must be configured to not affect any cookies that begin with edgio_.

Unless these conditions are met, the users will almost certainly receive a mix of content from both experiences in the A/B test, which can lead to a broken app and invalid A/B testing results.

Caching

When Edgio is behind a third-party CDN, we strongly recommend that all caching on it be turned off. If, for whatever reason, you cannot do this, it is then your responsibility to first purge the cache on Edgio, and only afterwards on CDN - in that exact order. Failing to do so will almost certainly lead to a situation where stale responses that you wanted to purge are served from Edgio to your CDN and cached there as non-stale responses before Edgio itself is purged (so-called cache poisoning).

Caching and traffic metrics are another area that is affected by CDN caching or any kind of traffic shaping where Edgio no longer sees all the traffic that your site is serving. If the third-party CDN is caching responses, then the perceived cache hit ratio on Edgio will be lower than it actually is (Edgio would only serve cache misses but never cache hits). If the third-party CDN is routing some traffic away from Edgio, then the traffic metrics will be affected as the Edgio Developer console will only provide statistics for the traffic that goes through Edgio.

Client IPs

When behind a third-party CDN, there is no way for Edgio to securely determine the IP of the user agent that originated the request, hence the x-0-client-ip header will contain the IP of the third-party CDN rather than the actual user agent. Relying on headers like x-forwarded-for to determine the IP necessarily introduces a security hole where attackers can simply spoof the IP and work around IP allow/block and geolocation blocking features of the plaform. Since Edgio uses the client IP to determine the geolocation headers, this means that geolocation headers will also have incorrect values.

In this situation, it is your responsibility to correctly set the client IP header and the dependent geolocation headers and pass it that way to Edgio and upstream servers.

For example, if you wish to set the x-0-client-ip and related geolocation header, to the header values injected by the third-party CDN, you can add a shim for this which go at the top of your router. 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.

JavaScript
1.match('/:splat*', ({ setRequestHeader, removeRequestHeader }) => {
2    setRequestHeader('x-0-client-ip', '${req:x-your-cdn-client-ip-header}')
3    removeRequestHeader('x-your-cdn-client-ip-header')
4    setRequestHeader('x-0-geo-country-code', '${req:x-your-cdn-geo-country-code-header}')
5    removeRequestHeader('x-your-cdn-geo-country-code-header')
6    setRequestHeader('x-0-geo-state-code', '${req:x-your-cdn-geo-state-code-header}')
7    removeRequestHeader('x-your-cdn-geo-state-code-header')
8    setRequestHeader('x-0-geo-city', '${req:x-your-cdn-geo-city-header}')
9    removeRequestHeader('x-your-cdn-geo-city-header')
10    setRequestHeader('x-0-geo-postal-code', '${req:x-your-cdn-geo-postal-code-header}')
11    removeRequestHeader('x-your-cdn-geo-postal-code-header')
12    setRequestHeader('x-0-geo-latitude', '${req:x-your-cdn-geo-latitude-header}')
13    removeRequestHeader('x-your-cdn-geo-latitude-header')
14    setRequestHeader('x-0-geo-longitude', '${req:x-your-cdn-geo-longitude-header}')
15    removeRequestHeader('x-your-cdn-geo-longitude-header')
16    setRequestHeader('x-0-geo-asn', '${req:x-your-cdn-geo-asn-header}')
17    removeRequestHeader('x-your-cdn-geo-asn-header')
18})

Security

As mentioned above, when not running on edge, it is impossible for Edgio to securely determine the client IP and other parameters on which the Edgio security features rely. We strongly recommend that in that case, all security be performed on the third-party CDN.

Access Logs

Edgio access logs continue to function normally but since they are not on the edge they may not include all of the traffic that comes to your site.

Allowing IPs

Edgio does not block any validly formed HTTP traffic coming from any IP so there is no need to specifically allow the backend IPs of your third-party CDN.