External Web Servers (Customer Origin Group)

A customer origin group provides the means through which you may serve traffic from:

• Your web servers (e.g., web hosting).
• Cloud hosting or cloud storage. Quickly create or connect to an existing Azure Block Blob storage container. Alternatively, you can point a customer origin group to your existing cloud implementation (e.g., AWS S3).

Set up a customer origin group by performing the following steps:

1. PCI Only

   Setting up a customer origin group for a site whose traffic must be served over a Payment Card Industry-certified (PCI) network requires assistance. Contact our technical customer support prior to setup.

2. Optional. Prepare for HTTPS delivery by requesting a TLS certificate through Certificate Provisioning System.

3. Create a customer origin group.

   A customer origin group maps your origin (e.g., your web servers) to a CDN URL through which your content may be served. A CDN URL consists of a system-defined base URL followed by the relative path to your content.

4. Optional. Create an edge CNAME configuration.

   Use an edge CNAME configuration to serve traffic via the CDN without having to update your links. This type of configuration maps a customer origin group to a CNAME recordA Canonical Name (CNAME) record is used to indicate that a hostname is an alias of another hostname. A CNAME record must be registered on a Domain Name System (DNS). This term should not be confused with edge CNAME..

5. Verify that your firewall accepts HTTP and/or HTTPS traffic from our network. Additionally, requests that originate from our network should not be rate limited.

   Learn more.

Key information:

• Upon creating a customer origin group, a dedicated CDN URLA system-defined URL that points to a CDN hostname. A CDN URL allows content delivery via our network. Simplify your CDN setup by also creating an edge CNAME configuration which potentially allows you to deliver traffic via the CDN using the same links as your current setup. is generated for it. The name assigned to your customer origin group is incorporated into this CDN URL. This allows our service to forward the request to the correct data source (i.e., your web servers) for the requested content.

  Learn more.

• Each customer origin group identifies a set of web server(s) by hostname or IP address. This configuration is known as an origin entry. A customer origin group may identify up to 10 hostnames or IP addresses per protocol (i.e., HTTP and HTTPS).

• Each customer origin group is specific to a platform.
• The maximum number of customer origin groups per platform is 100.

• Since CDN URLs are case-sensitive, note the case when assigning a name to a customer origin group.

  View sample scenario.

  This scenario assumes that you have created a customer origin group whose name is Marketing.

  The following CDN URL uses the proper case:

  https://wpc.0001.omegacdn.net/800001/Marketing/index.html

  The following CDN URL uses the incorrect case for the name of the customer origin group (i.e., Marketing) and therefore is invalid:

  https://wpc.0001.omegacdn.net/800001/marketing/index.html

• A customer origin group consists of one or more origin entries that identify the set of servers that will fulfill HTTP and/or HTTPS requests.

• It is strongly recommended to cloak your origin to protect it against attacks that directly target your web servers and thereby bypass the security provided by our CDN service.

• A list of origin groups are provided on the platform-specific Origins page. Filter this list by specifying a customer origin group name, origin entry name, hostname, or IP address. Searches are case-sensitive and search results will include partial matches.

  Clear a search by clicking the x or searching for a blank value.

  View a sample search scenario.

  Searching for "cdn" would include all of the following results:

  • cdn
  • mycdn
  • cdn2

  It would exclude all of the following results:

  • CDN
  • myCdn

Creating a Customer Origin Group

This section provides step-by-step instructions on how to create a customer origin group.

Key information:

• The DNS record corresponding to each hostname defined within a customer origin group must be fully propagated by your DNS service provider.

  Check DNS record propagation via the "dig" command-line tool, which is a networking tool that queries DNS name servers for a DNS record. Add the "+trace" parameter to instruct your DNS service provider to provide a direct response on the DNS record. The syntax for this command is provided below.

  dig hostname +trace

  In the bottom section of the response, you should see an A record that points the specified hostname to an IP address. This indicates that the DNS record has been fully propagated. An excerpt from a sample response is shown below.

  myorigin.example.com. 3600 IN A 10.10.10.101
  example.com. 3600 IN NS dns02.dnsauthority.com.
  example.com. 3600 IN NS dns01.dnsauthority.com.
  ;; Received 100 bytes from 100.100.100.101#53(100.100.100.101) in 20 ms
  
• As a precautionary measure, it is recommended to set a hostname's DNS TTLDefines the length of time, in seconds, that a DNS record will be cached by a recursive nameserver. to a low value until you have confirmed that our edge serverThis type of server is located near the edge of our network where its close proximity to your end-users allows it to deliver data more quickly than normal Internet communication. It is responsible for handling requests and caching assets.s can properly communicate with the origin server. A low DNS TTL reduces the amount of time that an improper DNS configuration will affect your origin server, while increasing the number of DNS queries sent to your DNS service provider.
• It may take up to an hour for your new customer origin group to take effect.

The maximum number of customer origin groups per platform is 100.

To create a customer origin group

Setting up a customer origin group for a site whose traffic must be served over a PCI-certified network requires assistance. Contact our technical customer support prior to setup.

1. Navigate to the Origins page corresponding to the desired platform. How?From the main menu, navigate to [HTTP Large, HTTP Small, or ADN] | Customer Origin.
2. Click Create.
3. Click Customer Origin.

4. Click within the Group option and then perform the following steps:

   1. Type the name that will be assigned to the new customer origin group.

      Use the following characters when defining this name: alphanumeric, hyphens, periods, and underscores.

      This name will be incorporated into the CDN URL (e.g., http://wpc.0001.omegacdn.net/800001/Customer Origin Group).

   2. Click + Add "Customer Origin Group Name".

5. In the Name option, type the name by which you will identify the hostname or IP address being defined.

   Use the following characters when defining this name: alphanumeric, hyphens, periods, and underscores.

6. Identify your web server(s) and how our network will communicate with them via one of the following methods:

   • End-to-End Encryption: This type of setup only allows the HTTPS protocol for the communication between clients, our network, and your web servers.

     View steps.

     HTTPS delivery requires the installation of a TLS certificate on our network. Request one through our Certificate Provisioning System.
     Learn more.

     1. From the Protocol Type option, select HTTPS Only.

     2. Set the Hostname or IP Address option to either an IP address or a hostname that points to your web server(s).

        Example:

        origin.example.com
     3. Set the Port option to the port over which our network will serve traffic to the above hostname or IP address.

   • Client-to-Edge Encryption: This type of setup only allows the HTTPS protocol for communication between clients and our network. Communication between our network and your web servers will be performed using the HTTP protocol.

     View steps.

     HTTPS delivery requires the installation of a TLS certificate on our network. Request one through our Certificate Provisioning System.
     Learn more.

     1. From the Protocol Type option, select HTTPS Only.

     2. Set the Hostname or IP Address option to http:// followed by either an IP address or a hostname that points to your web server(s).

        Example:

        http://origin.example.com

     3. Set the Port option to the port over which our network will serve traffic to the above hostname or IP address.

   • HTTP Only: Only allow the HTTP protocol for the communication between clients, our network, and your web servers.

     View steps.

     HTTPS requests cannot be served by a hostname or IP address set to this mode.

     1. From the Protocol Type option, select HTTP Only.

     2. Set the Hostname or IP Address option to either an IP address or a hostname that points to your web server(s).

        Example:

        origin.example.com

     3. Set the Port option to the port over which our network will serve traffic to the above hostname or IP address.

   • Match Client: Match the protocol defined in the client's request.

     View steps.

     HTTPS delivery requires the installation of a TLS certificate on our network. Request one through our Certificate Provisioning System.
     Learn more.

     Our network will serve HTTP traffic to your web servers over port 80, while HTTPS traffic will be served over port 443.

     1. From the Protocol Type option, select Match Client.

     2. Set the Hostname or IP Address option to either an IP address or a hostname that points to your web server(s).

        Example:

        origin.example.com

7. From the Primary option, determine how requests will be load balanced when multiple hostnames or IP addresses have been associated with a customer origin group.

   • Round-Robin: Make sure that the Primary option is disabled.
   • Primary/Failover: If the current hostname or IP address is the primary web server, then enable the Primary option. Otherwise, disable it.

8. From the Group Settings section, click HTTP Host Header. Verify that the Host Header option is set to one of the following:

   • A hostname defined in step 5.
   • An edge CNAME whose configuration points to this customer origin.
   • Blank. The request will determine the value assigned to the Host request header.

9. ADN Only

   Perform the following steps when creating a customer origin group for the ADN platform:

   1. Upload a sample asset to each server that has been specified for this customer origin group.

      Our servers use this asset to choose the optimal ADN Gateway servers and data routes for your customer origin group. The optimal file size for this sample asset is 5 KB.

   2. From the Group Settings section, click ADN Gateway.

   3. In the Validation Path option, specify a URL that points to a sample asset on your customer origin server.

      The hostname specified in this URL should match the one defined in the Host Header option unless that option has been set to blank.

   4. Mark or clear the Follow redirects option according to whether our service will respect a URL redirect for the URL defined in the previous step.
   5. Click Validate. If the result returns "200 OK" for all hostnames/IP addresses, then proceed to the next step.

10. Origin Shield Only

    Origin Shield, which must be purchased separately, is available on the HTTP Large and HTTP Small platforms.

    • Set up origin shield on a customer origin by performing the following steps:

      1. From the Group Settings section, click Origin Shield.
      2. Enable the Origin Shield option.

      3. Perform one of the following:

         • Set up a recommended origin shield configuration by enabling the Single POP option. You should then select the Origin Shield POP closest to your customer origin server(s) from the ALL POPs list.

         • Create a custom origin shield configuration by enabling the Multiple POPs option and then selecting the origin shield action that will take place for each region.

           Learn more.

      4. Use the PCI Certified Only option to determine whether you may select any Origin Shield POP or only those that are Payment Card Industry (PCI)-certified.
    • Set up a customer origin to handle all requests that are not served from cache by disabling the Origin Shield option.

11. Optional. From the Group Settings section, click Resolve to IPv6 or IPv4. Review whether requests will be resolved to IPv4 or IPv6.

    Learn more.

12. HTTPS Delivery Only

    Optional. If your customer origin group supports HTTPS delivery, click Origin TLS from the Group Settings section. Review your SNI setup and whether self-signed certificates will be allowed.

    Learn more.

13. Click Save to save your customer origin group.

14. Optional. Add another hostname or IP address to your customer origin group.

    1. Click Create.
    2. From the Group option, select the customer origin group created above.
    3. Repeat steps 4 - 6.
    4. Click Save.
    5. Repeat as needed.
15. Verify that the firewall for your web servers does not restrict access to the IP address blocks listed within the Whitelist IP Blocks page.

Modifying a Customer Origin Group

A customer origin group contains individual origin entries and settings that apply across the entire group. Modify a customer origin group by clicking within one of its origin entries.

If an edge CNAME points to a customer origin group, then you will not be allowed to switch one of its origin entries to a different customer origin group. Consider creating a new customer origin group. Alternatively, you can delete the edge CNAME configuration and then switch the desired origin entries to a different customer origin group.

It may take up to an hour for changes to your customer origin group to take effect.

To modify a customer origin group

1. Navigate to the Origins page corresponding to the desired platform. How?From the main menu, navigate to [HTTP Large, HTTP Small, or ADN] | Customer Origin.
2. Click on the desired customer origin group to expand it.
3. Click on the desired origin entry.
4. Make the desired changes to the origin entry. See steps 4 - 6 from the To create a customer origin group procedure above.
5. Make the desired changes to group settings. See steps 7 - 11 from the To create a customer origin group procedure above.
6. Click Save to save your customer origin group.

Deleting a Customer Origin Group

Permanently delete a customer origin group by deleting all of its origin entries and then deleting the customer origin group.

If an edge CNAME points to a customer origin group, then you will not be allowed to delete its last origin entry. Delete the corresponding edge CNAME configuration and then delete the last origin entry.

It may take up to an hour for customer origin group deletions to take effect.

To delete a customer origin group

1. Navigate to the Origins page corresponding to the desired platform. How?From the main menu, navigate to [HTTP Large, HTTP Small, or ADN] | Customer Origin.
2. Click on the desired customer origin group to expand it.
3. Hover over the desired origin entry and then click . When prompted, click Delete to confirm the deletion of the origin entry.
4. Repeat the previous step until you have deleted all of the origin entries associated with the desired customer origin group.
5. Click Create.
6. Click Customer Origin.
7. Click within the Group option.
8. Type the name of the desired customer origin group.

9. Delete the customer origin group by clicking the that appears next to it.

   If the icon is unavailable, then you should verify that all of its origin entries have been deleted.

Customer Origin Group Name

The Group option uniquely identifies your customer origin group. This name is included as a URL segment within a CDN URLA system-defined URL that points to a CDN hostname. A CDN URL allows content delivery via our network. Simplify your CDN setup by also creating an edge CNAME configuration which potentially allows you to deliver traffic via the CDN using the same links as your current setup. as indicated below.

Syntax:

Key information:

• Set up a friendlier and shorter URL (i.e., edge CNAME URLThis type of URL takes advantage of an edge CNAME configuration and a CNAME record to provide a friendlier alternative to a CDN URL. An edge CNAME URL is specific to the platform from which it was configured.) by creating an edge CNAME configuration and defining a CNAME record.
  Learn more.
• The name assigned to your customer origin group cannot be modified while an edge CNAME configuration points to it.
• Use the following characters when defining this name: alphanumeric, hyphens, periods, and underscores.
• CDN and edge CNAME URLs are case-sensitive.

Example

If the primary purpose of your web servers is to serve images, then you might create a customer origin group called images. An example of what a CDN URL for this type of customer origin might look like is provided below.

The above sample CDN URL points to the webroot on the server(s) associated with the images customer origin group. Append the desired relative path to the content that you would like to request. This relative path is highlighted in the following sample CDN URL:

Origin Entries

A customer origin group may consist of up to 10 origin entries per protocol. An origin entry identifies a set of web server(s) by hostname or IP address.

Create an origin entry by clicking Create from the Origins page. Set the Group option to the customer origin group to which the origin entry will be added.

Define a customer origin's web servers through the following options:

Option	Description
Name	Assigns a friendly name to an origin entry.
Protocol Type	Determines whether an origin entry will fulfill: HTTP Requests: Set this option to HTTP Only. HTTPS Requests: Set this option to HTTPS Only. HTTP and HTTPS Requests: You may either: Create two origin entries for the hostname or IP address where one origin entry is set to HTTP Only and the other one is set to HTTPS Only. Set this option to Match Client. Although this mode is easier than creating an additional origin entry, it provides less flexibility when determining the protocol and ports for edge to origin communicationRefers to traffic sent from our network to an origin server (e.g., your web server).. HTTPS delivery requires the installation of a TLS certificate on our network. Request one through our Certificate Provisioning System. Learn more.
Hostname or IP Address	Identifies the web server(s) that will be associated with the current origin entry via a hostname or IP address. If you selected either the HTTPS Only or HTTP Only mode in the Protocol Type option, then you may also define a protocol for edge to origin communication. You may not specify a hostname or IP address that points to our network. This type of configuration is disallowed since it may cause your traffic to infinitely loop within our network. Use any combination of hostnames and IP addresses when defining a customer origin group's origin entries. A hostname must be resolved to an IP address before a request can be forwarded to it. The Origin Configuration option defines how hostnames will be resolved to an IP address. Learn more. Syntax: HTTPS Only and HTTP Only Modes: ProtocolOptional. Replace with either "http://" or "https://".Hostname or IP Address If you choose to assign a protocol, make sure that all origin entries within a customer origin group for a given mode use the same protocol. For example, you may not configure some HTTPS Only origin entries to use the HTTP protocol and others to use the HTTPS protocol. Hostname Example: https://www.mydomain.com IPv6 Example: [1:2:3:4:5:6:7:8] Match Client Mode: Hostname or IP Address IPv4 Example: 10.10.10.255 Brackets are required when identifying an origin server through the use of IPv6 notation. This is the standard URI convention for IPv6 addresses.
Port	Determines the port for edge to origin communication. This option cannot be set when an origin entry has been configured to use Match Client mode. Default value: 80 | 443

Key information:

• An optimal configuration requires that the web servers specified for each customer origin group reside in relatively close vicinity to one another.

  The recommended setup for optimal performance for web servers located in disparate geographic regions is to create a customer origin group for each region.

• In order to avoid DNS latency when communicating with your web servers, our edge serverThis type of server is located near the edge of our network where its close proximity to your end-users allows it to deliver data more quickly than normal Internet communication. It is responsible for handling requests and caching assets.s proactively resolve each hostname defined in a customer origin group.

  Our edge servers respect the DNS TTLDefines the length of time, in seconds, that a DNS record will be cached by a recursive nameserver. for the DNS record corresponding to each hostname.

  If our edge servers are unable to resolve a hostname or if the hostname's DNS TTL has expired, then they will reattempt to resolve it at regular intervals until it is resolved. Since this action may incur additional charges by your DNS provider, it is recommended that all hostnames associated with a customer origin group be registered in DNS with a reasonable TTL (e.g., 3600 seconds or more).

• Defining multiple origin entries for either HTTP or HTTPS requests will cause requests to be load balanced across those origin servers for that protocol.
• A customer origin group supports up to 10 origin entries per protocol (i.e., HTTP or HTTPS).
• Our service will respond with a 404 Not Found error message when an origin entry has not been defined for the requested protocol (i.e., HTTP or HTTPS).
• Learn how to implement an HTTPS solution.
• Learn more about our IPv6 support.

HTTP Host Header

HTTP 1.1 requires a Host header to be sent with each request. A Host header identifies the hostname/IP address and port associated with a request. This information is especially useful when there are multiple virtual domains hosted on a single physical server or load-balanced set of servers.

Each customer origin group allows a Host header value to be configured. Typically, the Host header value should be set to either of the following:

• A hostname or IP address associated with the customer origin group being updated.

• A hostname corresponding to a CNAME record that meets the following requirements:

  • It points to our CDN service.

  • It has been associated with an edge CNAME configuration that points to the customer origin group whose Host header is being defined.

    

If the Host Header option is set to blank, then the request URI determines the value for the Host request header.

Load Balancing

A load balancing configuration defines how traffic will be managed between the edge of our network and a customer origin group for a particular protocol (i.e., HTTP or HTTPS).

• HTTP Traffic: The hostnames/IP addresses associated with the HTTP Only and Match Client modes are resolved into a list of IP addresses through DNS.

• HTTPS Traffic: A separate list of IP addresses is generated for the HTTPS Only and Match Client modes.

  A hostname must be resolved to an IP address before a request can be forwarded to it. The Origin Configuration option defines how hostnames will be resolved to an IP address.
  Learn more.

  HTTPS delivery requires the installation of a TLS certificate on our network. Request one through our Certificate Provisioning System.
  Learn more.

Traffic is load balanced when a customer origin group contains multiple origin entries for either the HTTP or HTTPS protocol. The customer origin group's load balancing configuration determines which IP address will handle the next request.

The available load balancing options are:

• Round Robin: This mode distributes requests evenly across all IP addresses generated for a particular protocol (i.e., HTTP or HTTPS). 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 disabling the Primary option on all origin entries associated with the desired customer origin group for a given protocol.

  View additional details.

  1. The first request is forwarded to the first IP address on the list.
  2. The next request is forwarded to the IP address listed directly below it. This step is repeated until a request is forwarded to the last IP address on the list.
  3. Last Server: If a request is forwarded to the last IP address on the list, then the next request is forwarded to the first IP address on the list.
• Primary/Failover: This mode indicates that a set of IP addresses form an ordered failover list. Set up primary/failover load balancing by enabling the Primary option on the desired origin entry for a given protocol. The order of the failover sequence can be controlled by rearranging origin entries from the Origins page.
  View additional details.

  1. All requests will be forwarded to the first IP address on the list.
  2. If the current server is unavailable, then the request will be sent to the next IP address on the list. This step is repeated until a server is able to honor the request.

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 server is considered unavailable when either of the following conditions are true:

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

The manner in which an unavailable server affects load balancing is described below.

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 the customer origin's load balancing configuration (i.e., round robin or primary & failover).
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.

IP Version

Hostnames associated with a customer origin group must be resolved to an IP address before a request can be served to it. The Origin Configuration option determines whether our servers will prefer to resolve a hostname to an IPv4 or IPv6 address.

Setting	Description
Default	Indicates that hostnames should be resolved to IPv4 addresses only. We reserve the right to change the behavior of this default setting at any time.
V6 Preferred Over V4	Indicates that our edge servers will resolve hostnames to IPv6 addresses whenever possible. If an IPv6 address for that hostname does not exist, then the hostname will be resolved to an IPv4 address.
V4 Preferred Over V6	Indicates that our edge servers will resolve hostnames to IPv4 addresses whenever possible. If an IPv4 address for that hostname does not exist, then the hostname will be resolved to an IPv6 address.
V4 Only	Indicates that hostnames should be resolved to IPv4 addresses only.
V6 Only	Indicates that hostnames should be resolved to IPv6 addresses only.

TLS Verification

Configure how our edge servers perform TLS verification with your origin servers.

HTTPS delivery requires the installation of a TLS certificate on our network. Request one through our Certificate Provisioning System.
Learn more.

SNI for HTTPS Origin Requests

Our network can leverage Server Name Indication (SNI) during the TLS handshake. If the SNI hint is not found, then your origin server's implementation determines the TLS certificate that will be returned.

Additionally, an edge server will compare the hostname used for the SNI hint to the certificate's Subject Alternative Name (SAN) or Common Name (CN) during the TLS handshake. If the hostname does not match, then the edge server will respond with a 502 Bad Gateway response.

To enable SNI

1. Modify the desired customer origin group.
2. From the Group Settings section, click Origin TLS.
3. Enable the Use SNI for HTTPS Origin Requests option.

4. From the SNI Hostname option, define the hostname that will be sent as a SNI hint during the TLS handshake.

   Our service will also perform a strict check using this hostname against the certificate's Subject Alternative Name (SAN) or Common Name (CN) during the TLS handshake.

5. Click Save to save your changes to your customer origin group.

Self-Signed Certificates

Our network can disable delivery when an edge server detects a self-signed certificate from the origin server during the TLS handshake. Enable the Disallow Self-Signed option to require our edge servers to respond with a 502 Bad Gateway response upon detecting a self-signed certificate from the origin server during the TLS handshake.

Public Key Pinning

Register the SHA-1 digest for the public key of your end-entity (i.e., leaf) certificate. 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 values defined within this option.

To pin your public key(s)

1. Generate a SHA-1 digest of your public key by running the following command on the server hosting your end-entity certificate(s):

   openssl x509 -in <public_cert>.crt -pubkey -noout | openssl rsa -pubin -outform DER | openssl dgst -sha1
2. Modify the desired customer origin group.
3. From the Group Settings section, click Origin TLS.
4. From the Subject Public Key Info Pin Verification option, paste the SHA-1 digest generated in step 1.
5. Register an additional public key by clicking + Pin and then repeating the above steps.
6. Click Save to save your changes to your customer origin group.

ADN Gateway

ADN Gateway servers are responsible for ensuring efficient data delivery between the CDN and external web servers (i.e., customer origin servers). Before an ADN Gateway server can assume this responsibility, our network will need to calculate the top three ADN Gateway servers that can provide the best performance for a customer origin group. This is calculated by requesting an asset from each web server associated with a customer origin group.

Configuration:

• File Size: The ideal type of asset to test the latency between ADN Gateway servers and your customer origin server(s) is one whose size is approximately 5 – 10 KB.
• Upload: Upload an asset to each server associated with the customer origin group.

  • Sample Asset: Download a sample performance test asset.

  • Multiple Servers: Make sure to upload the desired asset to the same location on all servers associated with the desired customer origin group.

• Set the Validation Path option to a URL that points to the desired asset.

  If a Host header value has been defined in the Host Header option, then it is recommended that the hostname defined in the validation path match that header value.

  Example:

  http://cdn.mydomain.com/_images/PerformanceTestObject_5k.gif

• Click Validate to check the communication with the current origin entry and to verify that the asset is accessible through that origin entry.

  • Error: If an error is reported, make sure to address the error and then reattempt the validation.

  • HTTP 200 OK: This test returns a HTTP 200 OK when it is able to successfully request the asset defined within the Validation Path option through the current origin entry.

    You should validate an origin entry upon its creation or modification.

Key information:

• If the asset defined in the Validation Path option needs to be moved, renamed, or deleted, make sure to perform the same action on all servers specified in your customer origin group and then update the Validation Path option to reflect this change.

• If a sub-optimal configuration is detected, then a message will appear directly below the ADN Gateways section. It is highly recommended that you verify that the detected issue will not affect your website's performance.

  Example

  If ADN detects that your site is redirecting URLs to another server, then this could lead to a situation where the wrong ADN Gateway server is being used to accelerate your website.

• Use the Follow redirects option to determine whether our edge servers will respect a URL redirect when validating the set of optimal ADN gateway servers for a customer origin group.
• Creating a customer origin will automatically revalidate the optimal path between the customer origin and ADN Gateway servers.

• The use of the Reselect option is recommended under the following circumstances:

  • A customer origin group setting or one of its origin entries is modified.
  • An ADN Gateway error is reported. Please resolve the error before reselecting the set of ADN Gateway servers that will be associated with the customer origin group.
• A new ADN Gateway configuration may take up to an hour to take effect. During this time period, the ADN Gateway servers previously assigned to a customer origin group will continue to accelerate your site.

Sample Validation Path

The following sample scenario provides an example as to how the Validation Path option should be configured.

Item	Scenario Description
HTTP Host Header	A customer origin server's HTTP Host header is set to: adn.mydomain.com
Sample Asset Configuration	A sample asset has been uploaded to all of the web servers associated with your customer origin group. The relative path to this sample asset is: /Permanent/Background.png
Validation Path	The Validation Path option should be set to: http://adn.mydomain.com/permanent/background.png

Key Response Headers

Configure your web server(s) or Rules Engine to include key headers in the response sent to the client to ensure optimal CDN performance.

Cache Revalidation

The web server(s) associated with a customer origin should include one of the following headers with each response that should be cached:

• Last-Modified (recommended)
• ETag

The above response headers allow our edge servers to perform cache revalidationRefers to the process that occurs when a request for stale content requires that our edge servers check for a new version of the requested content on the origin server. when staleIdentifies cached content whose TTL has expired. Our edge servers revalidate stale content with the origin server. This step ensures that the latest version of the requested content is served to the requester. content is requested. If both response headers are missing, then our edge servers will perform an unconditional GET request to the customer origin server.

QUIC

Allow QUIC-compatible clients to leverage QUIC by including the alt-svc header in the response.

The easiest way to enable QUIC for all CDN traffic is to add the QUIC feature under the Always match condition.

Learn more.

Setting Response Headers

Response headers may be defined via either of the following methods:

• Define them within your web server's configuration.

• Rules Engine: Create a rule that:

  1. Identifies the type of requests to which response header(s) will be added.
  2. Defines each response header that will be added to the response. Add a Modify Client Response Header feature for each desired response header.

Google QUIC

QUIC is an emerging technology that is developing at a rapid pace. For this reason, we are occasionally required to temporarily suspend this capability when upgrading our QUIC implementation. Although QUIC will be disabled during these maintenance windows, your traffic will continue to be accelerated via our network.

Google QUIC, which stands for Quick UDP Internet Connections, is a new transport protocol developed by Google that reduces latency and provides better HTTP/2 stream-multiplexing support when compared to TCP. QUIC provides functionality equivalent to TCP + TLS + HTTP/2 except that it is implemented over UDP.

QUIC is only supported for client-to-edge traffic to customer origins that have been configured to support TLS.
Learn more.

According to The Chromium Projects, it provides the following advantages over TCP + TLS + HTTP/2:

• Dramatically reduced connection establishment time
• Improved congestion control
• Multiplexing without head of line blocking
• Forward error correction
• Connection migration

QUIC Setup

Enable QUIC by setting up a rule within Rules Engine that either:

• Enables the QUIC Rules Engine feature for all traffic or the desired edge CNAMEs. This is the recommended method.

• Adds the alt-svc response header for all traffic or the desired edge CNAMEs.

  If you are manually adding the alt-svc response header, it is strongly recommended to use both QUIC Versions HTTP variables to define the v parameter. Explicitly defining the set of supported versions is strongly discouraged since you will need to manually update it whenever we add or drop support for a specific version.

To enable QUIC via Rules Engine

Before enabling QUIC, please verify that the desired customer origin(s) support TLS.

1. Create a draft.

2. Update a rule within that draft to define the condition(s) under which QUIC should be enabled.

   • All Traffic: If QUIC should be enabled for all traffic, then add the Always match condition.

   • Edge CNAME: If QUIC should only be enabled for specific edge CNAMEs, then add one or more Edge CNAME match condition(s).

     Use a Select First Match section to add more than one Edge CNAME match condition to a single rule.

3. Add the QUIC feature directly below the match condition(s) created in the previous step. Set it to Yes.
4. Click Save to save the rule.
5. Click Lock Draft as Policy to convert the draft into a policy.
6. Deploy the policy to the Production or Staging environment.

How Does QUIC Work?

Before a user agentRefers to software that acts on behalf of a user. For example, a web browser (e.g., FireFox, Chrome, and Internet Explorer) is a user agent. A web browser will make HTTP/HTTPS requests based on user actions (e.g., requesting a web site or clicking a link). may leverage QUIC, it must be informed via the alt-svc (Alternative Service) response header that it may communicate with the CDN via QUIC. This response header also informs the client the set of supported QUIC versions and the length of time that this data should be cached by the client.

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.

Sample alt-svc header name/value:

The above sample response header indicates to the client that:

• QUIC is only supported for traffic over port 443 as defined by the quic parameter.
• The user agent should treat the connection as fresh for 259,200 seconds (i.e., 3 days) as determined by the ma (max-age) parameter.

• Our CDN only supports QUIC versions defined within the v (version) parameter.

  We may add or drop support for QUIC versions at any time. Ensure that your configuration remains up-to-date through the QUIC feature.

WebSocket Protocol

The WebSocket protocol is a TCP-based protocol that enables an open, continuous, and full-duplex connection between a client (e.g., web browser) and a server. This allows a server to send data to a client without requiring the client to request it. In contrast, the HTTP protocol only allows a server to respond when a client requests content.

Leverage the WebSocket protocol for low latency applications that require real-time, interactive communication. For example, WebSocket communication improves the user experience for multiplayer games and chat applications by providing higher responsiveness via lower latency.

Key benefits:

• Full-Duplex Communication: The WebSocket protocol offers bidirectional communication between the server and the client. This allows both parties to communicate and exchange data at the same time.
• Eliminates Unnecessary Requests: A persistent connection between the client and the server means that the client does not need to constantly check for new data. Your server may now push the data to the client.
• Lower Latency: A persistent connection also reduces latency by eliminating the normal overhead required by HTTP (e.g., headers).

WebSocket Setup

Set up involves:

1. WebSocket Protocol Activation

   You must activate support for the WebSocket protocol before you can leverage it.

   Contact your CDN account manager to request support for the WebSocket protocol. We will determine whether to activate it based on an analysis of your use case.

2. Web Server Setup

   Verify that your web server supports the use of the WebSocket protocol. After which, you should implement a WebSocket server-side application and verify that it allows bidirectional communication with your client.

   Our network acts as a middleman between your client and server for bidirectional communication via the WebSocket protocol. If your web server does not properly support WebSocket communication, then a client's request to upgrade to the WebSocket protocol will fail and communication will proceed via HTTP.

3. Client Setup

   1. Verify that the client natively supports the WebSocket protocol. Most modern browsers already support the WebSocket protocol. If your custom application does not already support it, then you will need to add support for it before proceeding to the next step.

   2. Update your client to include the following request headers when initially requesting a connection that requires low latency:

      Connection: Upgrade

      Upgrade: websocket

      These headers indicate that the client wants to change the protocol from HTTP to WebSocket.

   3. Update your client to re-initiate the connection with the server upon disconnection.

      A client, server, or a network disruption may disconnect a WebSocket connection.

How Does the WebSocket Protocol Work?

A WebSocket connection starts when a client submits a request to the CDN over HTTP. This request must inform an edge serverThis type of server is located near the edge of our network where its close proximity to your end-users allows it to deliver data more quickly than normal Internet communication. It is responsible for handling requests and caching assets. that the client would like to upgrade the connection to use the WebSocket protocol via the following request headers:

If the WebSocket protocol has been activated on your account, an edge server will forward the request to your web server(s). Your web server must then either:

• Accept the request to upgrade to the WebSocket protocol with a 101 Switching Protocols response that contains the following response headers:

  Connection: Upgrade

  Upgrade: websocket

  An edge server will forward the response to your client. Once the client receives this response, the handshake will be complete and a WebSocket connection has been established. This connection allows both the client and the server to send control (i.e., Close, Ping, and Pong) and data frames to each other. This connection will persist until either the client or the server closes it.

  For the purpose of log data, all client/server communication within a single WebSocket connection is treated as a single log entry. Additionally, it is not logged until either the client or the server closes the connection.

• Deny the protocol upgrade request with a 4xx response. An edge server will forward this 4xx response to the client.

Firewall Access

For the purpose of fulfilling requests, our edge servers require access to all servers associated with a customer origin group. Please ensure that your firewall allows access to all of the IP blocks listed in the Whitelist IP Blocks page.

Export a list of the IPv4 and IPv6 blocks that should be whitelisted by clicking CSV from the Whitelist IP Blocks page.

The Whitelist IP Blocks page contains a superset of IP addresses that includes:

• The IP blocks defined within the CDN IP's page.
• The IP blocks for future POPs.

Once the IP blocks defined within the Whitelist IP Blocks page have been whitelisted on your firewall, it is unnecessary to add the IP blocks defined within the CDN IP's page.

Best Practices (Dynamic Application)

If your customer origin hosts a dynamic application, then it is highly recommended that you do not use a user's IP address to maintain a session instance. This type of configuration is unsupported, since the client does not connect directly to your web servers. Instead, the client connects to a server on our network, and then that server connects to your web server. If you would like to maintain a session for your dynamic application, we recommend that you use a cookie to identify the session. For example, a cookie could keep track of a unique ID for each client's session.

More Information

• Tutorial: Delivering Content over HTTP
• Tutorial: Delivering Content over HTTPS
• HTTPS
• Creating an Alias for a CDN URL
• Frequently Asked Questions - Content Delivery
• Frequently Asked Questions - Origin Shield
• CDN Request Explained
• Response (Response Headers)
• QUIC (Rules Engine feature)
• HTTP Variables
• Amazon Web Services - S3