Configuration Remap Plugin

This plugin allows you to override configuration directives dependent on remapping rules.

Purpose

Traffic Server provides a plethora of configuration options, but specifying the values of those options in records.yaml is global. All requests, regardless of the cache object or its origin, will be evaluated within the same collection of settings. Sometimes you may want Traffic Server to behave differently for portions of your cache.

Perhaps you have Negative Response Caching enabled, but you wish to greatly reduce the validity times for just one of your origin servers while allowing the rest of your origins to have their errors cached for long durations.

Or maybe you make use of Heuristic Expiration but require different fuzz times for various objects because of the nature of their content and expected lifetimes.

Any configuration directive which is overridable can be modified on a per-map basis with this plugin. This opens up a level of flexibility in your configurations for effectively managing and caching content with varied needs, without having to resort to multiple Traffic Server instances.

Installation

This plugin is considered stable and is included with Traffic Server by default. There are no special steps necessary for its installation.

Configuration

Configuration of this plugin is performed alongside the actual remapping rules which trigger the desired configuration directive changes. There are two methods available for specifying the actual directives and their modified values.

Inline Directives

In cases where you have very few remapping rules which modify directives, and they are modifying only a small number of directives, you may find it easiest to simply specify those directive changes in-line with your remapping rules. This is done by specifying key = value pairs, where the key is the configuration directive name and the value is its desired setting for the remapping rule.

For example, the enable proxy.config.url_remap.pristine_host_hdr for a single map rule, you would add the following to your remap.config:

map http://cdn.example.com/ http://origin.example.com/ \
    @plugin=conf_remap.so @pparam=proxy.config.url_remap.pristine_host_hdr=1

External Configuration

There may be situations in which you have many directives you wish to modify, or where multiple remapping rules perform the same directive changes. External configurations can simplify management of these rules, and help to reduce the possibility of transcription errors, or keeping all the directive settings in sync across all the remapping rules over time.

Instead of specifying the directives and their values in remap.config as you do with the in-line method, you place all the affected directives in a separate YAML file. The location and name is entirely up to you, but we’ll use /etc/trafficserver/cdn_conf_remap.yaml here. The contents of this file should mirror how configuration directives are written in records.yaml:

records:
  url_remap:
    pristine_host_hdr: 1

Your remap.config will then contain remapping rules that point to this external file:

map http://cdn.example.com/ http://some-server.example.com \
    @plugin=conf_remap.so @pparam=/etc/trafficserver/cdn_conf_remap.yaml

Your external configuration may contain as many directives as you wish.

Caveats

This plugin can only modify the values for those configuration directives which are overridable, meaning they are not fixed upon Traffic Server startup. While this generally shouldn’t prove too onerous a restriction, you should consult the individual directives’ documentation to confirm whether they may be overridden.

Further Reading

For more information about the implementation of overridable configuration directives, you may consult the developer’s documentation for TSHttpOverridableConfig.

Also if moving from a legacy config format, please have a look at Converting records.config to records.yaml.