Articles in this section

See more

CDN Invalidations: URL conventions invalidated for removed or replaced assets

Avatar
Daniel Mendoza
  • Updated
Follow

Standard invalidation method for most customers

CDN invalidation can be requested when you include the "invalidate" parameter when calling Upload API methods to change or delete an original asset. When those operations are performed using our Media Library UI, the "invalidate" parameter is included by default.

For most Cloudinary accounts and workflows, when you overwrite or delete an asset and CDN invalidation is requested, we invalidate all possible URLs for that asset using "hashes" that represent different parts of the asset's metadata, such as the asset's Public ID.
This method of invalidation is called "surrogate key invalidation", and was enabled for most Cloudinary customers before December 2020.

With this method, when we invalidate a specific asset, all URLs for original and derived copies of the asset can be invalidated in a single operation and no special configuration is needed. When you request invalidation via the API, CDN caches of the previous asset will be invalidated as expected.

URL-based invalidation for legacy workflows and configurations

For a small number of customers with custom configurations or using less common workflows with our CDN layer, that method of invalidation isn't supported and we use an older method of invalidation where specific URL patterns are invalidated for the asset.

For those customers, there are three possible URL patterns we can invalidate, depending on how you build your asset delivery URLs, and the difference between the options is how the version component is used in the delivery URL.

  1. (Default) Using no version component for assets in the root folder of your account, and including "v1" as the version for assets in subfolders
  2. With no version component, regardless of the folder path in the Public ID
  3. Using an asset's current version number, e.g. "v1610625835", for all assets in the account

If you're using option 3, the version in the URL should be kept up-to-date with the asset's current version number. This also provides a form of "cache-busting" because updating the version number in the URL will bypass the CDN's cache and any third-party caches not in Cloudinary's control, including corporate, ISP, or browser caches. In this case, if invalidation is requested we'll invalidate URLs containing the previous version number of the asset to account for possible delays in the version number being updated in your application's URLs (e.g. if moving from version "1610625835" to "1610625836", we'll invalidate URLs containing "/v1610625835/" )

 

Other considerations for invalidations

  • Invalidations are sent based on your account configuration at the time the existing asset is replaced or deleted.
  • Though most invalidations are processed in a few seconds, the process by which CDNs receive and process the invalidations is asynchronous, and it can take several minutes (or in rare circumstances, up to an hour) for the request to fully propagate throughout the CDNs
  • To invalidate the previous version of an asset via Upload API methods, the "invalidate" parameter should be explicitly defined in the API call (as it is not automatically applied to everything).
    • When using Admin API methods, the "invalidate" parameter is not enabled by default - we recommend using the Upload API for operations on specific assets, but if you're using the Admin API for infrequent or bulk operations, please contact us for more information about enabling invalidations on Admin API methods.
    • When deleting or renaming a resource through the Media Library, the "invalidate" parameter is sent automatically
  • If you're using Signed delivery URLs, please contact us so we can enable invalidation of signed URLs instead of unsigned URLs.

 

 

Related articles

Comments

0 comments

Article is closed for comments.