Origins

Setup #

• Each origin configuration identifies a set of web server(s) by hostname or IP address. You may specify up to 4 hostnames or IP addresses.
• Load balance requests to the web servers associated with an origin configuration using either primary/failover or round-robin mode.
• The maximum number of origin configurations per environment is 100.
• By default, our CDN forwards the Host header provided by the client when proxying requests to your origin server(s). You may override the client’s Host header by setting the Override Host Header option to the desired hostname. This forces our CDN to set the Host header to the specified hostname whenever it proxies traffic to the origin server(s) associated with this origin configuration.
  Overriding the Host header is useful when your origin implementation uses multiple virtual hosts or a virtual host with multiple aliases.
• Malicious actors may bypass the security provided by our service by directly targeting your origin server(s). We strongly recommend that you set up your firewall to only allow traffic from trusted sources (e.g., our network) and to obfuscate your origin.

1. Load the Origins page.
   1. From the Edgio Console, select the desired private space or organization.
   2. Select the desired property.
   3. From the left-hand pane, select the desired environment from under the Environments section.
   4. From the left-hand pane, select Origins.
2. Click + Add Origin.

   

3. In the Name option, assign a name to this origin configuration. This name should only consist of alphanumeric characters, hyphens, periods, and underscores.
   We recommend a unique, descriptive name to help you quickly map hostname(s) to this origin configuration.
4. Define one or more host(s). Each host determines how Edgio will communicate with your web server(s).

   

   1. In the Origin Hostname option, type a hostname or IP address that points to your web server(s).
   2. Optional. Set the Port option to the port over which our network will serve traffic to the above hostname or IP address.
   3. Optional. Set the IP Version Preference option to define a preference on how Edgio will resolve a hostname defined within the Origin Hostname option.
   4. Set the Scheme option to always serve traffic to your hosts over HTTPS, HTTP, or to match the client’s scheme. Matching a client’s scheme means that our network will serve HTTP traffic to your web servers over port 80, while HTTPS traffic will be served over port 443.
   5. Optional. Override the client’s Host header by setting the Override Host Header option to the desired hostname.
   6. Optional. Add another host to this origin configuration by clicking + Add Host and then performing steps 4.i - 4.v.
   7. Optional. Set the Balancer type option to the desired load balancing mode for requests proxied to your web servers.
5. Define TLS settings for this origin configuration through the Origin TLS Settings section.
   1. Most web servers require a SNI hint during the TLS handshake. Define this SNI hint through the Use SNI hint and enforce origin SAN/CN checking option. By default, this option is set to the value assigned to the Override Host Header option.
      Perform either of the following steps:
      • If your web server requires a SNI hint, enable the Use SNI option and then verify or set the SNI hint through the Use SNI hint and enforce origin SAN/CN checking option.
        Upon enabling SNI, our service will perform a strict check using this hostname against the certificate’s Subject Alternative Name (SAN) or Common Name (CN) during the TLS handshake.
      • If your web server does not use SNI, then you should disable both SNI options. You should also verify that the Use the following SNI hint and enforce origin SAN/CN checking option is set to a blank value.
   2. If your origin servers use a self-signed certificate, then you should toggle the Allow Self Signed Certs option to the on position (

      

      ). Otherwise, this option should be disabled.
   3. Set up certificate pinning by adding one or more public keys.
      1. Click + Add Pin.
      2. Paste the SHA-1 digest for the public key of your leaf certificate.
      3. Repeat steps 1 and 2 as needed.
6. Optional. Protect your origin by defining one or more shield POP(s). Click on the Shields section to expand it.
   1. Assign a POP location to the region closest to your web server(s).
      Upon configuring a region, all other regions will be updated from Bypass to the selected POP. This configuration means that cache misses from all regions will be proxied to the selected POP location.

      

   2. Optional. Assign a POP location to a different region.
      Upon configuring a second region, the remaining regions are automatically updated from the selected POP to Use the shield with the lowest RTT. This configuration means that cache misses from the remaining regions will be proxied to the shield POP that will provide the best performance.
      For example, the following configuration may potentially allow cache misses from the APAC region to be served through the shield location defined for the US West region (i.e., OXR).

      

   3. Optional. Repeat step 2 as needed.
   4. Optional. Configure cache misses from a specific region to always be proxied to your origin by selecting Bypass.
7. Optional. Advanced Configuration. Customize whether Edgio will submit retry requests for specific status codes through the Retry Status Codes section.
8. If you are finished making changes to this environment, click Deploy Changes.

Origin TLS Settings #

• SNI: An origin configuration’s Use SNI and the Use SNI hint and enforce origin SAN/CN checking options determine whether Edgio will:
  • Perform a strict check using the hostname defined within this option against the certificate’s Subject Alternative Name (SAN) or Common Name (CN) during the TLS handshake. If the hostname does not match, then we will respond with a 502 Bad Gateway response.
  • Provide a Server Name Indication (SNI) hint to your origin server during the TLS handshake. A SNI-enabled web server uses a SNI hint to determine the TLS certificate that will be returned.
  Enable both options and provide a SNI hint if your web servers require SNI. Otherwise, your web server will reject the request and our edge servers will respond with a 502 Bad Gateway response.
• By default, our network disables delivery and responds with a 502 Bad Gateway when we detect an origin server using a self-signed certificate during the TLS handshake. Allow Edgio to serve traffic when it detects a self-signed certificate by enabling the Allow Self-Signed Certs option.
• Register the SHA-1 digest for the public key of your end-entity (i.e., leaf) certificate within the Pinned Cert(s) option. After which, our edge servers will respond with a 502 Bad Gateway response when the SHA-1 digest for the public key detected from the origin server does not match one of the pinned certificates.

Retry Requests #

• The number of seconds that our edge servers will wait before retry: Determines the number of seconds that our edge servers will wait before retrying a request to that origin entry. If the retry request results in the same status code, then our edge servers will wait a slightly longer time before retrying the request again.
• Maximum number of request retries: Determines the maximum number of attempts that Edgio will make to connect to that origin entry.
• The maximum number of seconds our edge servers will wait before retry: Sets the maximum number of seconds that Edgio will wait between attempts to connect to an origin entry.
  Additionally, if the Ignore the Retry-After origin response header is disabled and the Retry-After response header returns a value larger than this setting, then Edgio will stop retrying the request and respond to the client with the response provided by the origin server.
• Ignore the Retry-After origin response header: Determines whether Edgio will ignore the Retry-After response header for this origin configuration.
  • Enabled: Edgio will ignore the Retry-After header provided in the response.
  • Disabled: The Retry-After response header takes precedence over the origin configuration’s The number of seconds that our edge servers will wait before retry setting. This setting will only be applicable when the Retry-After header is missing from the response.

System-Defined Origins #

• edgio_image_optimizer: Used for serving images through the image optimization feature.
• edgio_permanent_static: Used for serving static assets configured to persist across deployments.
• edgio_serverless: Used for serving requests through the Edgio cloud.
• edgio_self: Refers to the current environment and is used in Edge Functions for issuing fetch requests to itself.
• edgio_static: Used for serving static assets.

HTTP/3 #

• Once a QUIC-compatible user agent discovers that a server supports QUIC, it will attempt to leverage QUIC for all subsequent requests to the same domain until the connection ends.
• By default, QUIC is supported on the latest versions of Google Chrome, Chromium, and Opera. However, it may require enablement. If a user agent doesn’t support QUIC, then it will communicate with the CDN using HTTP/2 over TCP.
• Our QUIC implementation supports the Bottleneck Bandwidth and Round-trip propagation time (BBR) congestion control algorithm without requiring additional CDN setup. However, BBR will only be used when a QUIC-enabled client (e.g., Google Chrome) requests it.
• We strongly recommend that you define the alt-svc response header through the Set Response Headers (set_response_headers) feature and set the value to the %{quic_altsvc_versions} variable. This variable returns the QUIC versions supported by our service.
  We may add or drop support for QUIC versions at any time. Ensure that you only advertise supported versions through the %{quic_altsvc_versions} variable.
• Sample alt-svc header name/value: alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
  The above sample response header indicates to the client that:
  • HTTP/3 is only supported for traffic over port 443 as defined by the h3 parameter.
  • The user agent should treat the connection as fresh for 2,592,000 seconds (i.e., 30 days) as determined by the ma (max-age) parameter.

Load Balancing #

• Edgio generates a list of IP addresses by resolving the hostnames associated with an origin configuration. These IP addresses are listed according to the order in which the corresponding hosts are listed within your origin configuration.
• If an origin configuration allows Edgio to proxy requests using both HTTP and HTTPS, then Edgio will generate an ordered list of IP addresses for each HTTP scheme.
• The available load balancing options are:
  • Primary/Failover: This load balancing mode requires Edgio to:
    1. Proxy all traffic to the first IP address in the list.
    2. If the current server is unavailable, then Edgio will issue another request to the next IP address on the list. This step is repeated until a server is able to honor the request.
    Set up primary/failover load balancing by selecting Primary failover from the Balancer type option.
  • Round-robin: This mode distributes requests evenly across all IP addresses. If a server is unavailable, then the request will be sent to the next IP address on the list.
    Set up round-robin load balancing by selecting Round robin from the Balancer type option.
• The above load-balancing options are completely independent from any load balancing configuration that may already distribute traffic to your web servers. For instance, traffic for a single IP address might be load balanced across several physical servers.

Unavailable Servers #

• A TCP connection is refused.
• The connection times out.

1. Once a server is designated as unavailable, CDN traffic will not be load balanced to the corresponding hostname or IP address for a brief time period.
2. Upon the expiration of this time period, CDN traffic may once again flow through the corresponding hostname or IP address according to its position within your origin configuration.
3. If the server is still unavailable, then CDN traffic will not be load balanced to the corresponding hostname or IP address for a brief, but slightly longer time period.
4. Steps 2 and 3 repeat until the server becomes available.

Origin Hostname Resolution #