This criterion lets you match based on the
Content-Typeheader value in the HTTP response.
There are limits to what you can do with response-based matches. Some features might have been applied at the client request stage and you can't override them with the response settings. Consider the following case: the edge server fetches the no-store content from the origin at the request stage. That means you can't turn off a property configuration's no-store setting with a response-based match.
You can select the following logical conditions:
|Value||The Rule is True When...|
|is one of||the incoming request header includes any of the specified content types.|
|is not one of||the incoming request header doesn't include any of the specified content types.|
Select the Content-Type response header from the drop-down list. You can enter the value manually, for example
|*||matches zero or more characters||The rule includes a match with content type text/*. Possible valid results are both text/html and text/css.|
|?||matches a single character||The rule includes a match with content type text/cs?. Possible valid result is text/css.|
Allow wildcards in value: When enabled, allows * and ? wildcard matches among the values, so that specifying text/* matches both text/html and text/css.
Value case sensitivity: If you select this option, the content type has to match the case of the entry.
Updated 11 months ago