Real-Time Purge

Real-Time Purge allows you to instantly delete the cache of your content at Azion. When you update content at your origin, you must choose the best strategy for updating it in Azion’s cache.

When configuring your cache policies, you determine the amount of time you want your objects to be cached at Azion. When you update your content at the origin, Azion can continue providing a cached copy for as much time as you have set it to be cached. With Real-Time Purge, you can instantly delete the cache of your content at Azion, from either Edge Cache or Tiered Cache. This way, Azion system fetches the latest version of your content in the origin.

However, if specific cached objects must be removed at the edge before they expire, you have the option to purge cache with Real-Time Purge. Regular cache purging as part of your application helps you:

• Ensure that users receive the most up-to-date content and experience the latest changes to your application.
• Prevent users from seeing obsolete content.
• Deliver content that is compatible with modern browsers and devices.
• Provide dynamic content caching and API responses without sacrificing the user experience.
• Control how your objects are served by Azion.
• Manage obsolete or outdated objects, helping your developers to build reliable, resilient, and better performing solutions.

Best practices

To ensure safe and controlled cache purges, you should maintain version markup in an object name. When you update the object at your origin, you can add the version in the object name, forcing each modification of your content to be treated as a new object by Azion.

To version your objects, you can use a sequential number, a timestamp, or other mechanism that you think is most appropriate as a version markup. For example, instead of naming an image as image.jpg, you could name it image_1.jpg and, when you need to update it, change the version to image_2.jpg.

This way, each content update will be treated as a new object by Azion, which allows you to control which object a request should return, even if the user has the previous version locally saved in the browser cache or in some intermediate cache.

You’ll also be able to provide different versions of your objects to different users and simplify the rollback process in case of issues with your update.

DEL method

If you use the DEL method to remove the object from the cache instead of Real-Time Purge, the user’s first GET request will be made to the origin. However, this method prevents Azion from delivering stale objects if the origin is inaccessible, delivering an error page instead.

You can use the DEL if your goal is to:

• Remove content from Azion’s cache after it has been removed from the origin.
• Force the removal and later update of contents for which a timestamp is unreliable.
• Force the delivery of an error page instead of a stale object if your origin is inaccessible and Azion is unable to get the latest version of your content.

Layer

Real-Time Purge offers you two layers to purge your cache from:

• Edge Cache: purges cache kept with Azion at the edge.
• Tiered Cache: purges cache from the second layer at the edge. Can only be done when the Tiered Cache module is active.

URL purge

Purges cached objects by entering a list of URLs as an argument.

A URL purge is non-recursive, which means that only the URLs entered will be purged from the cache. The URLs are automatically converted to their respective cache keys, without considering any content variation in the same URL.

The expiration of content variations based on query string can be run using URL purge, since a query string is a component of the URL, as long as the arguments used for content variation are sent in the correct order in which they were presented. If you enabled Query String Sort, either sort the arguments in the request, or consider using cache key purge or wildcard purge as an alternative.

URL purge arguments

The URL format must respect the standard: scheme://host or just host, followed or not by a /path and the ?query-string. When the scheme isn’t informed, both HTTP and HTTPS contents will be purged.

For example:

• http://www.yourdomain.com
• http://static.yourdomain.com/include/site.css
• https://static.yourdomain.com/include/site.js
• dynamic.yourdomain.com/app.py?argument

Cache key purge

Purges cached objects by passing a list of cache keys as an argument.

You can specify an advanced cache key to identify different variations of an object, based on:

• Query string or query string sort arguments.
• Cookies when using Advanced Cache Key.
• Image format according to browser support when using Image Processor.

To purge all variations, you must search for the cache keys individually.

Wildcard purge

Purges cached object by giving a wildcard expression as an argument.

Wildcard purge arguments

The wildcard expression format must be according to the standard: scheme://host or just host, followed or not by a /path and the ?query-string, with an asterisk character (*) in the path or query string. You can even use multiple wildcards to match a complex pattern of a path.

For example:

• www.yourdomain.com/*
• static.yourdomain.com/include/*.css
• static.yourdomain.com/*/site.js
• static.yourdomain.com/static/images/image_1.jpg?ims=*
• www.yourdomain.com/alpha*
• www.yourdomain.com/*beta*
• www.yourdomain.com/*a*/charlie
• www.yourdomain.com/*a*/*a*
• www.yourdomain.com/*?b*
• www.yourdomain.com/*?*2*c=*

Application Accelerator purge

You can purge objects with content variation based on cookies or query strings using the Advanced Cache Key feature from the Application Accelerator module.

To remove objects with cookie-based variation, you can use a purge by cache key, entering all variations individually, or a purge by wildcard, using @@* at the end.

To purge objects with variation based on query string, you can use:

1. A cache key purge, entering all the variations individually.
2. A wildcard purge, using ?* at the end.
3. A URL purge, entering only the arguments used in the cache key in the URL.

If you use Query String Sort, the arguments must be sent in alphabetical order.

Image Processor purge

You can purge images that are treated by Image Processor.

In addition to host and path the cache key must include the separator ?, key-value pairs related to the type of processing, and the @@ separator for identifying image format variation supported by the browser. For example:

• httpstatic.yourdomain.com/static/images/image.jpg@@
• httpstatic.yourdomain.com/static/images/image.jpg@@webp
• httpstatic.yourdomain.com/static/images/image.jpg?ims=88x@@
• httpstatic.yourdomain.com/static/images/image.jpg?ims=88x@@webp

You can use a cache key purge, entering all variations individually, or a wildcard purge, using * at the end.

Large File Optimization purge

If you use the Large File Optimization feature in your application, large files might still remain in cache. To perform a purge in this case, you must list the cache keys for each fragment individually.

To purge all file fragments using this optimization, you can use a wildcard purge:

• static.yourdomain.com/media/file.mp4*

HTTP method purge

By default, Azion allows caching of GET and HEAD methods only. You can enable POST or OPTIONS caching with the Application Accelerator module.

To purge these objects, you can either use a cache key purge, entering all variations individually or a wildcard purge, using @@* at the end.

Purge confirmation

After creating a new purge, you’ll receive a successful message to confirm the creation. Then, the purge is queued for execution and will appear in the history once completed. This happens because the results may take some time to propagate to all edge nodes.

When necessary, you can query the purge history to filter the user who made the purge, the time, argument list, purge type, and method.

Limits

These are the default limits:

These are the default limits for each Service Plan: