Provided by: trafficserver_9.1.3+ds-1_amd64 bug


       cache.config  -  the 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

          After modifying cache.config, run traffic_ctl config reload to apply changes.


       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.

   Primary Destinations
       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 dest_domain.

              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.

   Secondary Specifiers
       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 port and scheme in the same rule, but you may not have two ports.

       port   Request URL port.

       scheme Request URL protocol (http or https).

       prefix Prefix in the path part of a URL.

       suffix File suffix in the URL.

       method Request URL method (get, put, post, trace, etc.).

       time   A  time range, such as 08:00-14:00. Specified using a 24-hour clock in the timezone
              of the Traffic Server server.

       src_ip Client IP address.

              A boolean value, true or 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.

       action One of the following values:

                          │Value                  │ Effect                           │
                          │never-cache            │ Never cache  specified  objects, │
                          │                       │ it   will   be   overwritten  by │
                          │                       │ ttl-in-cache.                    │
                          │ignore-no-cache        │ Ignore    all     Cache-Control: │
                          │                       │ no-cache headers.                │
                          │ignore-client-no-cache │ Ignore  Cache-Control:  no-cache │
                          │                       │ headers from client requests.    │
                          │ignore-server-no-cache │ Ignore  Cache-Control:  no-cache │
                          │                       │ headers   from   origin   server │
                          │                       │ responses.                       │

              Change the style of caching with regard to cookies. This effectively overrides  the
              configuration parameter proxy.config.http.cache.cache_responses_to_cookies and uses
              the same values with the same semantics. The override  happens  only  for  requests
              that match.

              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

              The  value  is the amount of time you want to keep the object(s) in the cache.  The
              following time formats are allowed:

              • d for days; for example: 2d

              • h for hours; for example: 10h

              • m for minutes; for example: 5m

              • s for seconds; for example: 20s

              • mixed units; for example: 1h15m20s

              For objects that are in cache, overrides the amount of time the object(s) are to be
              considered fresh. Use the same time formats as pin-in-cache.

              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-Control response headers
              from the origin server. Use the same time formats as pin-in-cache.


       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:

 prefix=foo suffix=js revalidate=7d
 suffix=js action=never-cache

       Reading that under the assumption that Traffic Server stops on the first match might  lead
       one  to  assume  that all Javascript files will be excluded from the Traffic Server cache,
       except for those whose paths begin with foo. This, however, is not correct.  Instead,  the
       first  rule  establishes that all Javascript files with the path prefix foo will be forced
       to revalidate every seven days, and then the second  rule  also  sets  an  action  on  all
       Javascript files, regardless of their path prefix, to never be cached at all. Because none
       of the Javascript files 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!
 prefix=foo suffix=js revalidate=7d
 suffix=js revalidate=1d

          # Correct!
 suffix=js revalidate=1d
 prefix=foo suffix=js revalidate=7d

       The  latter  accomplishes the implied goal of having a default, or global, timer for cache
       object revalidations on Javascript  files,  as  well  as  a  more  targeted  (and  longer)
       revalidation  time  on  just  those  Javascript files with a particular prefix. The former
       fails at this goal, because the second rule will  match  all  Javascript  files  and  will
       override any previous revalidate values that may have been set by prior rules.

   ttl-in-cache and never-cache
       When  multiple  rules  are  matched  in  the  same  request,  never-cache  will  always be
       overwritten by ttl-in-cache. For example:

          # ttl-in-cache=1d never-cache=false


       The following example configures Traffic Server to revalidate gif and jpeg objects in  the
       domain  every 6 hours, and all other objects in every hour. The
       rules are applied in the order listed.

 suffix=gif revalidate=6h
 suffix=jpeg revalidate=6h

       Force a specific regex to be in cache between 7-11pm of the server's time for 26 hours.

* time=19:00-23:00 ttl-in-cache=1d2h

       Prevent objects from being evicted from cache:

* pin-in-cache=1h