Request

The CDN serves content by handling each request through the following workflow:

This workflow is described below.

Phase	Action	Description
1	Request	A user requests content from the CDN. This request is automatically directed to the POPIdentifies a location on our network through which users can request and receive content. closest to that user.
2	Security	The CDN checks whether the requested content has been secured. If so, then the request must pass the minimum security requirements set for that content.
3	Check for Cached Content	Once the request has been authorized, the CDN checks for a cached version of the requested content. If freshIdentifies cached content that can be served directly by an edge server without requiring revalidation with an origin server. It also indicates that the cached content's TTL has not expired. content is found, then it is served immediately to the user. Otherwise, it is requested from the origin serverRefers to the server(s) where content served via the CDN is stored. There are two types of origin servers, which are CDN and customer origin servers. All requests that cannot be fulfilled directly by an edge server are forwarded to an origin server. For example, a request for content that has not been previously cached is forwarded from an edge server to an origin server. via a CAN gateway server.
4	Fetch and Deliver	The origin server responds with the requested content. This response is served to the user via the following route: Customer's Web Server CAN gateway Server POP (Phase 1) User's Device Routing the request/response via a CAN gateway server ensures optimal performance between your web servers and the edge of our network.
5	Cache	The CAN gateway server and 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. that served the requested content may then cache it.

A more detailed explanation for each phase is provided below.

Phase 1: Request

Sample CDN URL:

http://can.0001.transactcdn.com/800001/marketing/index.html

Sample edge CNAME URL:

http://cdn.example.com/index.html

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 CAN 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 CAN 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 a CAN 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 a CAN 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 CAN gateway server handling the request did not find a cached version of the requested content.
The CAN 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 a CAN gateway server to request the asset from a CDN or customer origin server. Once it starts receiving the asset from the origin server, a CAN gateway server will immediately start delivering it to the client that requested it via the edge server that forwarded the initial request.

A default CAN 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 CAN 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 a CAN 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://can.0001.transactcdn.com/800001/Images/Logo.png?no-cache