Summary of Matches Used to Revalidate Content
The following table is a summary of the matches used to revalidate content.
|URL Path||recursive-dirs||Match on the URL path components by name. Lets you invalidate all URLs that begin with a particular directory structure. Can nest only inside path matches.|
|sub-dirs-only||Match on all subdirectories of a given directory. Treats the
directory name like ‘*’, as in:
|this-dir||Constrains the invalidation to the current directory. Otherwise
it would apply to all sub- directories of the given directory.
Can nest only inside path matches.
|filename||See Caution below. Matches on the exact filename, nests only inside path matches.|
|Request Property||ext||Matches on the given file extensions. You can list multiple extensions and it is recursive, so that a single match will apply to all files with the given extension i n all directories unless you nest this inside a URL path match.|
|cookie||See Caution below. Matches on the cookie name or name and value. Useful if the site caches responses separately based on the presence of a cookie. For example, a cookie that identifies the language of the end client might be used to separate English content from French content in cache. Using this match, you would be able to invalidate one set of content without invalidating the other set.|
|cpcode-range||Matches a CPcode or range of codes. Useful if the site uses multiple CP-codes to segregate content.|
|arl-type||Matches on the type of the ARL (edge server configuration).|
|request-header||See Caution below. Matches on the name or name and value of the header. Useful for matching on the Host: in the request if many hostnames are served from a single origin site and the contents are cached separately based on hostname. This is useful when a client header is included in the Cache Key using the Force CacheID feature.|
|request-type||Matches on the source of the request (end user versus ESI processor, for example.) This is not generally a useful distinction for invalidations.|
|method||Matches on the method of the request. Method is a component of the cache key by default. This is useful if POST responses are being cached and you want to distinguish between POST and GET in your invalidation request.|
|protocol||Matches on the protocol (HTTP vs. HTTPS). Protocol is a component of the cache key by default, so this match is useful for invalidating one set of content but not the other.|
|query-string||See Caution below. Matches on the name or name and value of a query string argument. Useful if query arguments are being used to distinguish objects in cache by including the arguments in the cache key.|
|typecode||Matches on the typecode of the request v1 ARL. May be useful if you want to invalidate request objects that use a particular typecode. For example, all requests that use an Object ID under typecode 7.|
|response- header||response- header||See Caution below. Matches on header name or name and value. Useful if a custom identifier is used to tag content. It is then possible to invalidate the content that contains the custom identifier rather than identify the content by other properties.|
CAUTION: Use these matches with caution! You can create a large number of unique matches and thus build a large purge.data file and adversely affect site performance. See ECCU Limitations.