How does it work?
This criterion lets you match based on the content-type header 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.
Operators
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 text/html
| Wildcard | Description | 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 include a match with content type text/cs?. A possible valid result is text/css. |
Additional options
- 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.