Request

Phase 1: Request

Content can be delivered through our network by requesting it using a CDN or edge CNAME URL.

Sample CDN URL (HTTP Large):

Sample edge CNAME URL:

Requests are handled by the point-of-presence (POP) closest to the requesterRefers to the user that requested content.. This reduces potential latency caused by the last mile. Additionally, it allows the request to quickly reach our optimized network routes.

The CDN hostnameRefers to a system-defined hostname that is specific to your customer account and a CDN service. and origin identifierA two digit value (e.g., 00 and 80) that identifies how a request will be routed through our CDN. associated with the request will be interpreted to determine the platform and the type of service that the user is requesting. An edge server then uses this information to determine whether the requested content has been secured.

Although an 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. does not contain a CDN hostname or an origin identifier, our edge servers will rewrite edge CNAME URLs to the corresponding CDN URL.

Phase 2: Security

The first check performed by an edge server in a POP is to find out whether the requested content has been secured. We offer the following methods for securing your content:

• Country Filtering
• Token-Based Authentication
• Rules Engine
• Web Application Firewall

If the request fails to meet any of the above security requirements, then an edge server will deny the request. No additional steps will be taken.

Country Filtering

Country Filtering allows you to secure content by directory. If the requested content resides in a secured directory, then the location of the user requesting the content determines whether the request will be authorized. If the request is denied, then the HTTP client will receive a 403 Forbidden status code.

Country Filtering is applied recursively to a secured location. For example, an asset that is located in a subfolder of a secured directory will still be protected by Country Filtering.

Token-Based Authentication

If the requested content has been secured through Token-Based Authentication, then an edge server will look for a token value in the query string. If it finds one, then the token value will be decrypted according to the encryption key(s) specified for the platform in question. A check will then be performed to see whether the HTTP client (e.g., browser) meets the security requirements defined by the decrypted token value.

Token-Based Authentication allows content to be secured by folder location or through Rules Engine.

By default, an HTTP client will receive a 403 Forbidden status code when any of the following conditions are true for an asset protected by Token-Based Authentication:

• The CDN or edge CNAME URL did not include a token value in the query string.
• The specified token was invalid. This occurs when a token was generated using an invalid encryption key.
• The HTTP client did not meet the token requirements.

Instead of returning a 403 Forbidden status code for the cases mentioned above, you can take advantage of custom denial handling to redirect users or to report a different HTTP status code.

Rules Engine

Rules Engine is a powerful tool that can be used for a variety of purposes. One feature provided in this tool is Deny Access (403). This feature will return a 403 Forbidden status code to the HTTP client whenever a user-defined set of conditions are met.

Web Application Firewall

Web Application Firewall (WAF) is designed to:

• Secure an origin server against malicious attacks. Use this feature to identify the set of traffic that will be screened, the conditions under which requests are deemed as threats, and how threats will be handled.
• Protect your web servers from excessive requests. Use this feature to restrict the number of requests that the CDN may forward to your web servers. Once the specified rate is exceeded, requests will be throttled to the specified rate. Requests that exceed this rate may either be dropped, redirected, sent a custom response, or simply be logged.

Phase 3: Check for Cached Content

If the requested asset passes all of the above security requirements, then a check is performed to see whether the asset is currently cached on the 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. handling the request.

Check for Content Freshness

If a cached version of the requested asset is found on the edge server handling the request, then a check for content freshness will be performed (as illustrated below).

Learn more.

The Origin Shield feature, which must be purchased separately, provides an intermediate cache layer between your origin server and our POPs.
Learn how Origin Shield handles requests for cached content.

If the cached version of the requested asset contains a Cache-Control: must-revalidate header value, then our edge and Origin Shield servers will honor it. This means that they will always check the origin server for a newer version of a stale asset with this header value.

Phase 4: Fetch and Deliver

A new version of the requested content will need to be retrieved from the origin server under either of the following conditions:

• The requested content is not cached on the edge server handling the request.
• A cached version of the requested content was found but its TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server. has expired.

Either of the above conditions will cause 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. on the respective POP to request the asset from a CDN or customer origin server. Once it starts receiving the asset from the origin server, the edge server will immediately start delivering it to the client that requested it.

Phase 5: Cache

Once the entire asset has been retrieved from the origin server, it will be cached on that edge server provided that the following conditions are met: 

Condition	Description
1st or 2nd Hit Caching	By default, content must be requested twice before it is cached on an edge server.
Cache Policy	The Cache-Control and Expires headers provided in the origin server's response determine whether the requested content will be cached. If those response headers are missing, then it will be cached with a max-age of 7 daysThis means that a cached version of that asset will be stored on the POP and it will be treated as fresh content for 7 days..

Rules Engine, which must be purchased separately, can be used to customize how our CDN caches assets. For example, our CDN may be configured to cache an asset even if a user aborts his/her download.

Phase 1: Request

Sample CDN URL:

Sample edge CNAME URL:

Requests are handled by the point-of-presence (POP) closest to the requesterRefers to the user that requested content.. This reduces potential latency caused by the last mile. Additionally, it allows the request to quickly reach our optimized network routes.

The CDN hostnameRefers to a system-defined hostname that is specific to your customer account and a CDN service. and origin identifierA two digit value (e.g., 00 and 80) that identifies how a request will be routed through our CDN. associated with the request will be interpreted to determine the platform and the type of service that the user is requesting. An edge server then uses this information to determine whether the requested content has been secured.

Although an 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. does not contain a CDN hostname or an origin identifier, our edge servers will rewrite edge CNAME URLs to the corresponding CDN URL.

Phase 2: Security

The first check performed by an edge server in a POP is to find out whether the requested content has been secured. We offer the following methods for securing your content:

• Country Filtering
• Token-Based Authentication
• Rules Engine
• Web Application Firewall

If the request fails to meet any of the above security requirements, then an edge server will deny the request. No additional steps will be taken.

Country Filtering

Country Filtering allows you to secure content by directory. If the requested content resides in a secured directory, then the location of the user requesting the content determines whether the request will be authorized. If the request is denied, then the HTTP client will receive a 403 Forbidden status code.

Country Filtering is applied recursively to a secured location. For example, an asset that is located in a subfolder of a secured directory will still be protected by Country Filtering.

Token-Based Authentication

If the requested content has been secured through Token-Based Authentication, then an edge server will look for a token value in the query string. If it finds one, then the token value will be decrypted according to the encryption key(s) specified for the platform in question. A check will then be performed to see whether the HTTP client (e.g., browser) meets the security requirements defined by the decrypted token value.

Token-Based Authentication allows content to be secured by folder location or through Rules Engine.

By default, an HTTP client will receive a 403 Forbidden status code when any of the following conditions are true for an asset protected by Token-Based Authentication:

• The CDN or edge CNAME URL did not include a token value in the query string.
• The specified token was invalid. This occurs when a token was generated using an invalid encryption key.
• The HTTP client did not meet the token requirements.

Instead of returning a 403 Forbidden status code for the cases mentioned above, you can take advantage of custom denial handling to redirect users or to report a different HTTP status code.

Rules Engine

Rules Engine is a powerful tool that can be used for a variety of purposes. One feature provided in this tool is Deny Access (403). This feature will return a 403 Forbidden status code to the HTTP client whenever a user-defined set of conditions are met.

Web Application Firewall

Web Application Firewall (WAF) is designed to:

• Secure an origin server against malicious attacks. Use this feature to identify the set of traffic that will be screened, the conditions under which requests are deemed as threats, and how threats will be handled.
• Protect your web servers from excessive requests. Use this feature to restrict the number of requests that the CDN may forward to your web servers. Once the specified rate is exceeded, requests will be throttled to the specified rate. Requests that exceed this rate may either be dropped, redirected, sent a custom response, or simply be logged.

Phase 3: Check for Cached Content

If the requested asset passes all of the above security requirements, then a check is performed to see whether the asset is currently cached on the 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. handling the request.

Due to the dynamic nature of content served from the ADN platform, the caching mechanism is bypassed by default. By default, a cached version of your content should not be found. In which case, the request would be handled as described in Phase 4: Fetch and Deliver.

Check for Content Freshness

If a cached version of the requested asset is found on the edge server handling the request, then a check for content freshness will be performed.

If the cached version of the requested asset contains a Cache-Control: must-revalidate header value, then our edge and ADN gateway servers will honor it. This means that they will always check the origin server for a newer version of a stale asset with this header value.

Learn more.

Phase 4: Fetch and Deliver

A new version of the requested content will need to be retrieved from an ADN gateway server under either of the following conditions:

• The edge server handling the request did not find a cached version of the requested content.
• The edge server handling the request found a cached version of the requested content but its TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server. has expired.

Either of the above conditions will cause 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. on the respective POP to request the asset from an ADN gateway server. At which point, a new version of the requested content will need to be retrieved from the origin server under either of the following conditions:

• The ADN gateway server handling the request did not find a cached version of the requested content.
• The ADN gateway server handling the request found a cached version of the requested content but its TTLTime to Live. Refers to the amount of time that a cached asset is still considered fresh. Our edge servers will continue to serve a cached version of an asset while its TTL has not expired. An asset's TTL is calculated by the Cache-Control and Expires headers associated with the response sent by the origin server. has expired.

Either of the above conditions will cause an ADN gateway server to request the asset from a CDN or customer origin server. Once it starts receiving the asset from the origin server, an ADN gateway server will immediately start delivering it to the client that requested it via the edge server that forwarded the initial request.

A default ADN configuration does not cache content and therefore a cached version of the requested content should not be found.

Phase 5: Cache

Once the entire asset has been retrieved from the origin server, it will be cached on the corresponding ADN gateway server and edge server provided that all of the following conditions are met: 

Condition	Description
2nd Hit Caching	By default, content must be requested twice before it is cached on an ADN gateway server or an edge server.
Cache Policy	The Cache-Control and Expires headers provided in the origin server's response determine whether the requested content will be cached. If those response headers are missing, then it will be cached with a max-age of 7 daysThis means that a cached version of that asset will be stored on the POP and it will be treated as fresh content for 7 days..
Bypass Cache	Rule Engine's Bypass Cache feature must be disabled for the requested content.

Rules Engine, which must be purchased separately, can be used to customize how our CDN caches assets. For example, our CDN may be configured to cache an asset even if a user aborts his/her download.

Key information:

• Ensure that dynamic content is not cached by a user agent (e.g., browser) by either:

  • Configuring your web server to add a Pragma: no-cache or a Cache-control: no-cache directive to the response generated for that content.

  • Enabling the Bypass Cache feature from within Rules Engine.

• Override an asset's cache headers and prevent it from being cached by specifying "no-cache" as a query string parameter when requesting it.

  Sample request URL:

  http://adn.0001.omegacdn.net/800001/Images/Logo.png?no-cache