cache.config file allows you to overrule the origin’s cache
policies. You can add caching rules to specify the following:
- Not to cache objects from specific IP addresses.
- How long to pin particular objects in the cache.
- How long to consider cached objects as fresh.
- Whether to ignore no-cache directives from the server.
Generally, using this file to define cache policies is an antipattern. It’s usually better to have the origin specify the cache policy via the Cache-Control: header. That way, all the business logic stays with the content generation. The origin is in a much better position to know which content can be safely cached, and for how long. It can make fine grained decisions, changing Cache-Control: header value per object. This file allows for some overrides but, is relatively crude compared to what the origin can provide.
Each line in the
cache.config file contains a caching rule. Traffic Server
recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value
You can use more than one secondary specifier in a rule. However, you cannot repeat a secondary specifier. The following list shows the possible primary destinations with allowed values.
The primary destination field on each line is used to restrict the requests to which the caching rule will apply.
- A requested domain name. Traffic Server matches the host name of the destination from the URL in the request.
- Alias for
- A requested IP address. Traffic Server matches the IP address of the destination in the request.
- A regular expression to be tested against the destination host name in the request.
- A regular expression to be tested against the URL in the request.
The secondary specifiers are optional and may be used to further restrict
which requests are impacted by the caching rule. Multiple secondary specifiers
may be used within a single rule, though each type of specifier can appear at
most one time. In other words, you may have both a
the same rule, but you may not have two
- Request URL port.
- Request URL protocol (http or https).
- Prefix in the path part of a URL.
- File suffix in the URL.
- Request URL method (get, put, post, trace, etc.).
- A time range, such as 08:00-14:00. Specified using a 24-hour clock in the timezone of the Traffic Server server.
- Client IP address.
- A boolean value,
false, specifying if the rule should match (or not match) a transaction originating from an internal API. This is useful to differentiate transactions originating from a Traffic Server plugin.
The final component of a caching rule is the action, which determines what Traffic Server will do with all objects matching the primary destinations and secondary specifiers of the rule in question.
One of the following values:
Never cache specified objects.
Cache-Control: no-cacheheaders from client requests.
Cache-Control: no-cacheheaders from origin server responses.
Preserves objects in cache, preventing them from being overwritten. Does not affect objects that are determined not to be cacheable. This setting can have performance issues, and severely affect the cache. For instance, if the primary destination matches all objects, once the cache is full, no new objects could get written as nothing would be evicted. Similarly, for each cache-miss, each object would incur extra checks to determine if the object it would replace could be overwritten.
The value is the amount of time you want to keep the object(s) in the cache. The following time formats are allowed:
dfor days; for example: 2d
hfor hours; for example: 10h
mfor minutes; for example: 5m
sfor seconds; for example: 20s
- mixed units; for example: 1h15m20s
- For objects that are in cache, overrides the the amount of time the object(s)
are to be considered fresh. Use the same time formats as
- Forces object(s) to become cached, as if they had a
Cache-Control: max-age:<time>header. Can be overruled by requests with cookies. The value is the amount of time object(s) are to be kept in the cache, regardless of
Cache-Controlresponse headers from the origin server. Use the same time formats as
Matching Multiple Rules¶
When multiple rules are specified in
cache.config, Traffic Server will check all
of them in order for each request. Thus, two rules which match the same request
but have conflicting actions will result in their actions being compounded. In
other words, Traffic Server does not stop on the first match.
In some cases, this may lead to confusing behavior. For example, consider the following two rules:
dest_domain=example.com prefix=foo suffix=js revalidate=7d dest_domain=example.com suffix=js action=never-cache
Reading that under the assumption that Traffic Server stops on the first match might lead
except for those whose paths begin with
foo. This, however, is not correct.
foo will be forced to revalidate every seven days, and then the
will be cached at all, the first rule is effectively voided.
A similar example, but at least one with a correct solution, might be an attempt to set differing values for the same action, as so:
# Incorrect! dest_domain=example.com prefix=foo suffix=js revalidate=7d dest_domain=example.com suffix=js revalidate=1d # Correct! dest_domain=example.com suffix=js revalidate=1d dest_domain=example.com prefix=foo suffix=js revalidate=7d
The latter accomplishes the implied goal of having a default, or global, timer
prefix. The former fails at this goal, because the second rule will match all
revalidate values that may
have been set by prior rules.
The following example configures Traffic Server to revalidate
objects in the domain
mydomain.com every 6 hours, and all other objects in
mydomain.com every hour. The rules are applied in the order listed.
dest_domain=mydomain.com revalidate=1h dest_domain=mydomain.com suffix=gif revalidate=6h dest_domain=mydomain.com suffix=jpeg revalidate=6h
Force a specific regex to be in cache between 7-11pm of the server’s time for 26 hours.
url_regex=example.com/articles/popular.* time=19:00-23:00 ttl-in-cache=1d2h
Prevent objects from being evicted from cache: