Configuring CloudEDGE CDN Caching Policies

Configure CloudEDGE CDN caching through CDN controls

After you enable CloudEDGE CDN (also known as Webscale CDN) for your application, you can use the Webscale Control Panel to configure caching policies through CDN controls. These policies define how Webscale CDN processes requests and responses, including what happens when Webscale CDN forwards requests to your application.

CDN controls allow you to run custom JavaScript at key points of the traffic pipeline via the CloudEDGE Workers feature, including as traffic transits to your application and after your application generates a response. This allows for easy extension to the capability of your application without changing your deployed code. For more information about the CloudEDGE Workers feature, see CloudEDGE Workers Overview.

Topics

Webscale CDN caching

Webscale CDN uses your CDN provider to cache resources. All HTTP requests and responses pass through the Webscale CDN cache even if they are not cachable.

By default, Webscale CDN does not cache assets and forwards all HTTP requests to your application servers. If you have enabled the Webscale Dynamic Site Cache feature for your proxies, Site Cache caches resources according to its own caching policies. It determines if the resource exists in its cache by converting the request into a cache key. If the resource exists, the response is served from there. If the cache does not have the resource, Webscale forwards the request to your web servers.

You can use CDN controls to configure caching policies for Webscale CDN. Each CDN control defines how Webscale CDN responds to a particular incoming request. When you create CDN controls, you define policies that determine how and what Webscale CDN caches.

CDN controls basics

The configuration of each CDN control must include a request path. When Webscale CDN receives a request, it compares the request path to the CDN control paths. It selects the first CDN control that matches according to the order in which they are configured in the Webscale Control Panel.

If Webscale CDN finds a match, it uses the cache key configuration of that CDN control to generate a cache key. Webscale CDN then uses this key to search for the resource in its cache.

  • If Webscale CDN finds the resource, a cache “hit” occurs and it returns the resource.
  • If Webscale CDN does not find the resource, a cache “miss” occurs and it forwards the request to your application. The forwarded request only includes the headers, cookies, and query parameters that the CDN control configuration included.

Optionally, you can specify the following configuration settings.

  • Duration of time that a resource can be cached before it expires
  • How Webscale CDN generates the cache key for a request
  • Headers, cookies, and query parameters that Webscale CDN includes on the application request

Specify optional settings

Webscale CDN uses the cache key to access the cache. It then determines if the cache contains the appropriate resource for the request. If the cache has the resource and it has not expired, Webscale CDN serves the cached resource.

CDN control settings can also determine the HTTP headers, cookies, and query parameters that Webscale CDN includes on requests that it sends to your application servers after cache misses.

If the path of a request does not match the path of any CDN control, the default policy runs. It sends the request with its HTTP headers, cookies, and query parameters to origin.

Reorder CDN controls

If a user creates multiple CDN controls, they display in a list in the Controls section of the CDN page by creation date (oldest to newest with the oldest at the top of the list) unless you have reordered the CDN controls in the list.

When the user selects a control in the list, the control’s configuration is displayed in the right pane. The configuration includes the control’s path pattern; how the cache key is generated for matching requests; headers, cookies and query parameters to pass through after cache misses; and any associated CloudEDGE workers

Webscale CDN compares requests to CDN controls based on their order in the list. It searches from top to bottom to find a match.

CloudEDGE Workers

Through the CloudEDGE Workers feature, CDN controls optionally allow you to augment a request that Webscale CDN forwards to origin after a cache miss or a response that origin returns to Webscale CDN.

Custom JavaScript enables you to extend your application’s functionality without changing your application code. The JavaScript source files include functions, each of which can process requests or responses but not both. The file that includes your JavaScript source files is known as a handler file. A handler incorporates the handler file.

When configuring a CDN control, you can associate up to two handlers with the control (one for requests and the other for responses). Associating handlers with a control creates a worker that runs the JavaScript function.

The Webscale Image Manager is a worker that you can use with Webscale CDN. It rapidly optimizes and processes images while maintaining image quality. Image Manager also helps embed images on your website and mobile applications to drive user engagement.

Access the CDN page

You can create CDN controls through the Controls section of the CDN page for your application. The Controls section only displays after you enable Webscale CDN. For more information on how to enable Webscale CDN, see Introduction to Configuring Webscale CDN and Completing Webscale CDN Configuration.

To access CDN controls settings

  1. Click the three vertical dots menu icon on the upper-right corner of the application box and select Edit.

    Select edit application

    -or-

    On your application page, click the Actions menu icon and select Edit.

    Select edit application
  2. On the sidebar menu, click CDN.

    When you have enabled Webscale CDN, the Controls section displays in the CDN page.

    CDN page

Further reading

Have questions not answered here? Please Contact Support to get more help.


Last modified November 10, 2020