match

The cache, invalidation and tag rule configurations all use match sections to limit the configuration to specific requests and responses.

Each match section contains one or more match criteria for requests. All criteria are regular expressions. For instance:

match:
    host: ^login.example.com$
    path: ^/$

host

type: string

A regular expression to limit the caching rules to specific hosts, when you serve more than one host from your Symfony application.

Tip

To simplify caching of a site that offers front-end editing, put the editing on a separate (sub-)domain. Then define a first rule matching that domain with host and set max-age: 0 to make sure your caching proxy never caches the editing domain.

path

type: string

For example, path: ^/ will match every request. To only match the home page, use path: ^/$.

methods

type: array

Can be used to limit caching rules to specific HTTP methods like GET requests. Note that the rule effect is not applied to unsafe methods, not even when you set the methods here:

match:
    methods: [PUT, DELETE]

ips

type: array

An array that can be used to limit the rules to a specified set of request client IP addresses.

Note

If you use a caching proxy and want specific IPs to see different headers, you need to forward the client IP to the backend. Otherwise, the backend only sees the caching proxy IP. See Trusting Proxies in the Symfony documentation.

attributes

type: array

An array of request attributes to match against. Each attribute is interpreted as a regular expression.

_controller

type: string

Controller name regular expression. Note that this is the controller name used in the route, so it depends on your route configuration whether you need Acme\\TestBundle\\Controller\\NameController::hello or acme_test.controller.name:helloAction for controllers as services.

Warning

Symfony always expands the short notation in route definitions. Even if you define your route as AcmeTestBundle:Name:hello you still need to use the long form here. If you use a service however, the compiled route still uses the service name and you need to match on that. If you mixed both, you can do a regular expression like ^(Acme\\TestBundle|acme_test.controller).

_route

type: string

Route name regular expression. To match a single route:

match:
    attributes:
        _route: ^articles_index$

To match multiple routes:

match:
    attributes:
        _route: ^articles.*|news$

Note that even for the request attributes, your criteria are interpreted as regular expressions.

match:
    attributes: { _controller: ^AcmeBundle:Default:.* }

additional_cacheable_status

type: array

By default, a rule will only match cacheable status codes: 200, 203, 300, 301, 302, 404 and 410 (as described in the RFC 7231).

additional_cacheable_status let you define a list of additional HTTP status codes of the response for which to also apply the rule.

match:
    additional_cacheable_status: [400, 403]

match_response

type: string

Note

match_response requires the ExpressionLanguage component.

An ExpressionLanguage expression to decide whether the response should have the effect applied. If not set, headers are applied if the request is safe. The expression can access the Response object with the response variable. For example, to handle all failed requests, you can do:

-
    match:
        match_response: response.getStatusCode() >= 400
    # ...

You cannot set both match_response and additional_cacheable_status inside the same rule.