Appendix E - Configuration Files

This appendix describes the Traffic Server configuration files that you can edit. For a list of all the configuration files used by Traffic Server, including files that you must not edit, refer to the Traffic Server Installation Guide.

bypass.config

The bypass.config file contains static bypass rules that Traffic Server uses in transparent proxy caching mode. Static bypass rules instruct Traffic Server to bypass certain incoming client requests so they are served by the origin server. The bypass.config file also accepts Dynamic Deny Bypass Rules.

You can configure three types of static bypass rules:

IMPORTANT: After you modify the bypass.config file, you must restart Traffic Server.

Format

Bypass rules follow the format below:
bypass src ipaddress | dst ipaddress | src ipaddress AND dst ipaddress

The following table describes the variables.

Option

Description

src ipaddress

Specifies the source (client) IP address in incoming requests Traffic Server must bypass.

The variable ipaddress can be one of the following:

- A simple IP address, such as 123.45.67.8
- In CIDR (Classless Inter-Domain Routing) format, such as 1.1.1.0/24
- A range separated by a dash, such as 1.1.1.1-2.2.2.2
- Any combination of the above separated by commas, such as 1.1.1.0/24, 25.25.25.25, 123.1.23.1-123.1.23.123

dst ipaddress

Specifies the destination (origin server) IP address in incoming requests Traffic Server must bypass.

The variable ipaddress can be one of the following:

- A simple IP address, such as 123.45.67.8
- In CIDR (Classless Inter-Domain Routing) format, such as 1.1.1.0/24
- A range separated by a dash, such as 1.1.1.1-2.2.2.2
- Any combination of the above separated by commas, such as 1.1.1.0/24, 25.25.25.25, 123.1.23.1-123.1.23.123

src ipaddress AND dst ipaddress

Specifies the source and destination IP address pair Traffic Server must bypass.

The variable ipaddress must be a single IP address, such as 123.45.67.8

Dynamic Deny Bypass Rules

In addition to static bypass rules, the bypass.config file also accepts dynamic deny bypass rules that prevent Traffic Server from bypassing certain incoming client requests dynamically (a deny bypass rule can prevent Traffic Server from bypassing itself). Dynamic deny bypass rules can be source, destination, or source/destination and have the following format:
deny_dyn_bypass src ipaddress | dst ipaddress | src ipaddresss AND ipaddress

For a description of the options, refer to the table above. For the dynamic deny bypass rules to work, you must set the variable proxy.config.arm.bypass_dynamic_enabled to 1 in the records.config file.

IMPORTANT: Static bypass rules overwrite dynamic deny bypass rules. If a static bypass rule and a dynamic bypass rule contain the same IP address, then the dynamic deny bypass rule will be ignored.

Examples

The following example shows source, destination, and source/destination bypass rules:
bypass src 1.1.1.0/24, 25.25.25.25, 128.252.11.11-128.252.11.255
bypass dst 24.24.24.0/24
bypass src 25.25.25.25 AND dst 24.24.24.0

The following example shows source, destination, and source/destination dynamic deny bypass rules:
deny_dyn_bypass src 128.252.11.11-128.252.11.255
deny_dyn_bypass dst 111.111.11.1
deny_dyn_bypass src 111.11.11.1 AND dst 111.11.1.1

cache.config

The cache.config file defines how Traffic Server caches web objects. You can add caching rules to specify the following:

IMPORTANT: After you modify the cache.config file, navigate to the Traffic Server bin directory; then run the traffic_line -x command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

Format

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 table lists the possible primary destinations with allowed values.

Primary Destination

Allowed Value

dest_domain

A requested domain name. Traffic Server matches the domain name of the destination from the URL in the request.

dest_host

A requested hostname. Traffic Server matches the hostname of the destination from the URL in the request.

dest_ip

A requested IP address. Traffic Server matches the IP address of the destination in the request.

url_regex

A regular expression to be found in a URL.

The secondary specifiers are optional in the cache.config file. The following table lists possible secondary specifiers with allowed values.

Secondary Specifier

Allowed Value

port

A requested URL port.

scheme

A request URL protocol: http or https.

prefix

A prefix in the path part of a URL.

suffix

A file suffix in the URL.

method

A request URL method: get, put, post, trace.

time

A time range, such as 08:00-14:00.

src_ip

A client IP address.

The following table lists possible actions and their allowed values.

Action

Value

action

One of the following values:

never-cache configures Traffic Server to never cache specified objects.
ignore-no-cache configures Traffic Server to ignore all Cache-Control: no-cache headers.
ignore-client-no-cache configures Traffic Server to ignore Cache-Control: no-cache headers from client requests.
ignore-server-no-cache configures Traffic Server to ignore Cache-Control: no-cache headers from origin server responses.

pin-in-cache

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

revalidate

The amount of time object(s) are to be considered fresh. Use the same time formats as pin-in-cache .

ttl-in-cache

The amount of time object(s) are to be kept in the cache, regardless of Cache-Control response headers. Use the same time formats as pin-in-cache and revalidate .

Examples

The following example configures Traffic Server to revalidate gif and jpeg 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 suffix=gif revalidate=6h
dest_domain=mydomain.com suffix=jpeg revalidate=6h
dest_domain=mydomain.com revalidate=1h

congestion.config

The congestion.config file enables you to configure Traffic Server to stop forwarding HTTP requests to origin servers when they become congested, and then send the client a message to retry the congested origin server later. After you modify the congestion.control file, navigate to the Traffic Server bin directory; then run the traffic_line -x command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster. Traffic Server uses the congestion.config file only if you enable the Congestion Control option.

You can create rules in the congestion.config file to specify:

Format

Each line in congestion.config must follow the format below. Traffic Server applies the rules in the order listed, starting at the top of the file.
Traffic Server recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value

The following table lists possible primary destinations with allowed values.

Primary Destination

Allowed Value

dest_domain

A requested domain name.

dest_host

A requested hostname.

dest_ip

A requested IP address.

url_regex

A regular expression to be found in a URL.

The secondary specifiers are optional in the congestion.config file. The following table lists possible secondary specifiers with allowed values. You can use more than one secondary specifier in a rule; however, you cannot repeat a secondary specifier.

Secondary Specifier

Allowed Value

port

A requested URL port or range of ports.

prefix

A prefix in the path part of a URL.

The following table lists the possible tags and their allowed values.

Tag

Allowed Value

max_connection_failures

The maximum number of connection failures allowed within the fail window described below before Traffic Server marks the origin server as congested. The default value is 5.

fail_window

The time period during which the maximum number of connection failures can occur before Traffic Server marks the origin server as congested. The default value is 120 seconds.

proxy_retry_interval

The number of seconds that Traffic Server waits before contacting a congested origin server again. The default value is 10 seconds

client_wait_interval

The number of seconds that the client is advised to wait before retrying the congested origin server. The default value is 300 seconds.

wait_interval_alpha

The upper limit for a random number that is added to the wait interval. The default value is 30 seconds.

live_os_conn_timeout

The connection timeout to the live (uncongested) origin server. The default value is 60 seconds.
If a client stops a request before the timeout occurs, then Traffic Server does not record a connection failure.

live_os_conn_retries

The maximum number of retries allowed to the live (uncongested) origin server. The default value is 2.

dead_os_conn_timeout

The connection timeout to the congested origin server. The default value is 15 seconds.

dead_os_conn_retries

The maximum number of retries allowed to the congested origin server. The default value is 1.

max_connection

The maximum number of connections allowed from Traffic Server to the origin server. The default value is -1.

error_page

The error page sent to the client when a server is congested. You must enclose the value in quotes; the default value is "congestion#retryAfter".
The error page is sent only if the Custom Responses option is enabled (refer to HTTP Responses).

congestion_scheme

Specifies if Traffic Server applies the rule on a per-host ("per_host") or per-IP basis ("per_ip"). The default value is "per_ip"; you must enclose the value in quotes.
For example: if the server www.host1.com has two IP addresses and you use the tag value "per_ip", then each IP address has its own number of connection failures and is marked as congested independently. If you use the tag value "per_host" and the server www.host1.com is marked as congested, then both IP addresses are marked as congested.

Examples

The following congestion.config rule configures Traffic Server to stop forwarding requests to the server www.host.com on port 80 (HTTP traffic) if the server is congested, according to the timeouts specified. Traffic Server uses the default tag values because no tag has been specified.
dest_host=www.host.com port=80

You can use one or more tags in a rule, but each tag must have one value only. If you specify no tags in the rule, then Traffic Server uses default values.

You can override any of the default tag values by adding configuration variables at the end of records.config as follows:
CONFIG proxy.config.http.congestion_control.default.tag INT|STRING value
where tag is one of the tags described in the table under congestion.config and value is the value you want to use.

For example:
CONFIG
proxy.config.http.congestion_control.default.congestion_scheme STRING per_host

IMPORTANT: Rules in the congestion.config file override the following variables in the records.config file:

proxy.config.http.connect_attempts_max_retries
proxy.config.http.connect_attempts_max_retries_dead_server
proxy.config.http.connect_attempts_rr_retries
proxy.config.http.connect_attempts_timeout
proxy.config.http.down_server.cache_time
proxy.config.http.down_server.abort_threshold

filter.config

The filter.config file enables you to deny or allow particular requests and strip header information from client requests. After you modify filter.config, you must restart Traffic Server.

Format

Each line in filter.config contains a filtering rule. Traffic Server applies the rules in the order listed, starting at the top of the file.
Traffic Server recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value

The following table lists possible primary destinations with their allowed values.

Primary Destination

Allowed Value

dest_domain

A requested domain name. Traffic Server matches the domain name of the destination from the URL in the request.

dest_host

A requested hostname. Traffic Server matches the hostname of the destination from the URL in the request.

dest_ip

A requested IP address. Traffic Server matches the IP address of the destination in the request.

url_regex

A regular expression to be found in a URL.

The secondary specifiers are optional in the filter.config file. The following table lists the possible secondary specifiers and their allowed values. You can use more than one secondary specifier in a rule; however, you cannot repeat a secondary specifier.

The following table lists possible actions with allowed values.

Secondary Specifier

Allowed Value

port

A requested URL port.

scheme

A request URL protocol: http or https.

prefix

A prefix in the path part of a URL.

suffix

A file suffix in the URL.

method

A request URL method. You can specify one of the following:
get
post
put
trace
PUSH

Note: If the PUSH option is enabled (the PUSH option lets you deliver content directly to the cache without user request), then you must add a filtering rule with the PUSH action to ensure that only known source IP addresses implement PUSH requests to the cache. To enable the PUSH option, set the configuration variable proxy.config.http.push_method_enabled to 1 in the records.config file.

time

A time range, such as 08:00-14:00.

src_ip

A client IP address.
Note: src_ip is not supported for PNA content.

Examples

The following example configures Traffic Server to keep the client IP address header for URL requests that contain the regular expression giraffes and whose path prefix is /habitat:
url_regex=giraffes prefix=/habitat keep_hdr=client_ip

The following example configures Traffic Server to strip all cookies from client requests destined for the origin server www.server1.com:
dest_host=www.server1.com strip_hdr=cookie

The following example configures Traffic Server to disallow puts to the origin server www.server2.com:
dest_host=www.server2.com method=put action=deny

The following example configures Traffic Server to allow only the host associated with the IP address 11.11.1.1 to deliver content directly into the cache (PUSH). A deny rule is also included to prevent unauthorized users from pushing content into the cache.
dest_domain=. src_ip=11.11.1.1 method=PUSH action=allow
dest_domain=. method=PUSH action=deny

Traffic Server applies the rules in the order listed in the filter.config file. For example, the sample filter.config file below configures Traffic Server to do the following:

dest_host=internal.com action=ldap server=ldap.com dn="o=ldap.com"
dest_host=server1.com action=allow
dest_host=naughty.com action=deny
dest_host=401k.fidelity.com action=ldap server=ldap.com:389 dn="o=ldap.com" attr=ou attr_val="Accounting Department"
dest_ip=0.0.0.0-255.255.255.255 action=lda

hosting.config

The hosting.config file enables you to assign cache partitions to specific origin servers and/or domains so that you can manage cache space efficiently and restrict disk usage. For step-by-step instructions on partitioning the cache according to origin servers and/or domains, refer to Partitioning the Cache According to Origin Server or Domain.
Before you can assign cache partitions to specific origin servers and/or domains, you must first partition your cache according to size and protocol in the partition.config file. For step-by-step instructions about partitioning your cache, refer to Partitioning the Cache. For a description of the partition.config file, refer to partition.config.

After you modify hosting.config, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply your changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

IMPORTANT: The partition configuration must be the same on all nodes in a cluster.

Format

Each line in the hosting.config file must have one of the following formats:
hostname= hostname partition= partition_numbers
domain= domain_name partition= partition_numbers

where hostname is the fully-qualified hostname of the origin server whose content you want to store on a particular partition (for example, www.myhost.com); domain_name is the domain whose content you want to store on a particular partition(for example, mydomain.com); and partition_numbers is a comma-separated list of the partitions on which you want to store the content that belongs to the origin server or domain listed. The partition numbers must be valid numbers listed in the partition.config file.

Note: To allocate more than one partition to an origin server or domain, you must enter the partitions in a comma-separated list on one line, as shown in the example below. The hosting.config file cannot contain multiple entries for the same origin server or domain.

Generic Partition

When configuring the hosting.config file, you must assign a generic partition to use for content that does not belong to any of the origin servers or domains listed. If all partitions for a particular origin server become corrupt, Traffic Server will also use the generic partition to store content for that origin server.

The generic partition must have the following format:
hostname=* partition=partition_numbers
where partition_numbers is a comma-separated list of generic partitions.

Examples

The following example configures Traffic Server to store content from the domain mydomain.com in partition 1 and content from www.myhost.com in partition 2. Traffic Server stores content from all other origin servers in partitions 3 and 4.

domain=mydomain.com partition=1
hostname=www.myhost.com partition=2
hostname=* partition=3,

icp.config

The icp.config file defines ICP peers (parent and sibling caches).

IMPORTANT: After you modify the icp.config file, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply the changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

Format

Each line in the icp.config file contains the name and configuration information for a single ICP peer in the following format:
host : host_IP : peer_type : proxy_port : icp_port : MC_on : MC_IP : MC_TTL :

Each field is described in the following table.

Field

Description

host

The hostname of the ICP peer.
This field is optional; if you do not specify the hostname of the ICP peer, you must specify the IP address.

host _IP

The IP address of the ICP peer.
This field is optional; if you do not specify the IP address of the ICP peer, you must specify the hostname.

ctype

Use the following options:

1 to indicate an ICP parent cache
2 to indicate an ICP sibling cache

proxy_port

The port number of the TCP port used by the ICP peer for proxy communication.

icp_port

The port number of the UDP port used by the ICP peer for ICP communication.

Examples

The following example configuration is for three nodes: the local host, one parent, and one sibling.

localhost:0.0.0.0:3:8080:3130:0:0.0.0.0:1
host1:123.12.1.23:1:8080:3131:0:0.0.0.0:1
host2:123.12.1.24:2:8080:3131:0:0.0.0.0:1

ip_allow.config

The ip_allow.config file controls client access to the Traffic Server proxy cache. You can specify ranges of IP addresses that are allowed to use the Traffic Server as a web proxy cache.
After you modify the ip_allow.config file, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

Format

Each line in the ip_allow.config file must have the following format:
src_ip=ipaddress action=ip_allow | ip_deny

where ipaddress is the IP address or range of IP addresses of the clients allowed to access the Traffic Server proxy cache, the action ip_allow enables the specified clients to access the Traffic Server proxy cache, and ip_deny denies the specified clients to access the Traffic Server proxy cache.

By default, the ip_allow.config file contains the following line, which allows all clients to access the Traffic Server proxy cache. To restrict access, comment out or delete this line before adding rules:
src_ip=0.0.0.0-255.255.255.255 action=ip_allow

Examples

The following example enables all clients to access the Traffic Server proxy cache:
src_ip=0.0.0.0-255.255.255.255 action=ip_allow

The following example allows all clients on a specific subnet to access the Traffic Server proxy cache:
src_ip=123.12.3.000-123.12.3.123 action=ip_allow

The following example denies all clients on a specific subnet to access the Traffic Server proxy cache:
src_ip=123.45.6.0-123.45.6.123 action=ip_deny

logs.config

The logs.config file establishes and formats traditional custom transaction log files.
Although Traffic Server supports traditional custom logging, you should use the more versatile XML-based custom logging (refer to Using the Custom Format and logs_xml.config). If you opt to use traditional custom logging instead of the more versatile XML-based custom logging, then you must enable the traditional custom logging option manually (refer to Support for Traditional Custom Logging).

IMPORTANT: After you modify logs.config, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

Format

Each line in the logs.config file establishes and formats a custom transaction log file. Lines consist of the following fields, separated by colons (:).

Field

Allowed Inputs

format

All lines must begin with the word format .

activation flag

Specifies if the custom log file is activated. You can specify one of the following options:

enabled
disabled

unique format identifier

You must use a unique integer for each custom log file you create.

format name

The name for the format you define.

format string

Identifies the printf -style format string specifying the field symbols to be displayed and how they should look in ASCII. Refer to this Appendix for a list of the available field symbols and their meanings.

Field symbols are indicated by %< field_symbol > format. For example: to indicate that chi is the client host IP and not the string chi to be printed, enter % <chi> .

file name

The name of the custom log file you create.

file type

The format of the file: ASCII or BINARY.

file header data

The header text. Enter none if you do not want header text; enter the text of the header if you want your custom log file to have a header.

Examples

The following example shows a custom log format for a file named minimalist. It records the client host IP address (chi), the client request universal resource identifier (cqu), and the proxy response status code (pssc).
format:enabled:1:minimal:%<chi> / %<cqu> / %<pssc>:minimalist:ASCII:none

The output file for the above example format is:
123.12.3.123 / GET http://earth/ocean/index.html HTTP/1.0 / 200

The following example shows a custom log format for a file named test. It records the User-Agent value of the client request header (cqh) and the Retry-After value of the proxy response header (psh).
format:enabled:1:test:%<{User-Agent}cqh> %<{Retry-After}psh>:test:ASCII:none

WELF

Traffic Server supports WELF, the WebTrends Enhanced Log format, so you can analyze Traffic Server log files with WebTrends reporting tools. A predefined custom format for WELF is provided in the logs.config file. To create a WELF format log file, comment out the following section at the end of the file and replace <FORMAT_ID> with a unique integer.

#format:enabled:<FORMAT_ID>:welf:id=firewall time="%<cqtd> %<cqtt>" fw=%<phn> pri=6 proto=%<cqus> duration=%<ttmsf> sent=%<psql> rcvd=%<cqhl> src=%<chi> dst=%<shi> dstname=%<shn> user=%<caun> op=%<cqhm> arg="%<cqup>" result=%<pssc> ref="%<{Referer}cqh>" agent="%<{user-agent}cqh>" cache=%<crc>:welf:ASCII:none

#

log_hosts.config

To record HTTP transactions for different origin servers in separate log files, you must list each origin server hostname in the log_hosts.config file. In addition, you must enable the HTTP Host Log Splitting option. You should use the same log_hosts.config file on every Traffic Server node in your cluster. After you modify the log_hosts.config file, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply the changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

Format

Each line in the log_hosts.config file has the following format:
hostname

where hostname is the hostname of the origin server.

Tip: You can specify keywords in the log_hosts.config file to record all transactions from origin servers with the specified keyword in their names in a separate log file. See the example below.

Examples

The following example configures Traffic Server to create separate log files containing all HTTP transactions for the origin servers webserver1, webserver2, and webserver3.

webserver1
webserver2
webserver3

The following example records all HTTP transactions from origin servers that contain sports in their names. For example: sports.yahoo.com and www.foxsports.com in a log file called squid-sport.log (the Squid format is enabled).

sports

logs_xml.config

The logs_xml.config file defines the custom log file formats, filters, and processing options. The format of this file is modeled after XML, the Extensible Markup Language.

Format

The logs_xml.config file contains the specifications below:

The logs_xml.config file ignores extra white space, blank lines, and all comments.

LogFormat

The following table lists LogFormat specifications.

Field

Allowed Inputs

<Name = "valid_format_name"/>

Required. Valid format names include any name except squid, common, extended, or extended2, which are pre-defined formats. There is no default for this tag.

<Format = "valid_format_specification"/>

Required. A valid format specification is a printf-style string describing each log entry when formatted for ASCII output. Use %< field > as a placeholder for valid field names. For more information, refer to Custom Logging Fields.

The specified field can be one of the following types:

  • Simple. For example: %<cqu>
  • A field within a container, such as an HTTP header or a statistic. Fields of this type have the syntax: %<{ field } container >
  • Aggregates, such as COUNT, SUM, AVG, FIRST, LAST. Fields of this type have the syntax: %<operator ( field )>
  • Note: You cannot create a format specification that contains both aggregate operators and regular fields.

<Interval = "aggregate_interval_secs"/>

Use this tag when the format contains aggregate operators. The value "aggregate_interval_secs" represents the number of seconds between individual aggregate values being produced.

The valid set of aggregate operators are:
COUNT
SUM
AVG
FIRST
LAST

LogFilters

The following table lists the LogFilter specifications.

Field

Allowed Inputs

<Name = "valid_filter_name"/>

Required. All filters must be uniquely named.

<Condition = "valid_log_field valid_operator valid_comparison_value"/>

Required. This field contains the following elements:

valid_log_field - the field that will be compared against the given value. For more information, refer to Logging Format Cross-Reference.

valid_operator_field - any one of the following: MATCH , CASE_INSENSITIVE_MATCH , CONTAIN , CASE_INSENSITIVE_CONTAIN.

  • MATCH is true if the field and value are identical (case-sensitive).
  • CASE_INSENSITIVE_MATCH is similar to MATCH, except that it is case-insensitive.
  • CONTAIN is true if the field contains the value (the value is a substring of the field).
  • CASE_INSENSITIVE_CONTAIN is a case-insensitive version of CONTAIN.

valid_comparison_value - any string or integer matching the field type. For integer values, all of the operators are equivalent and mean that the field must be equal to the specified value.

Note: There are no negative comparison operators. If you want to specify a negative condition, then use the Action field to REJECT the record.

<Action = "valid_action_field"/>

This instructs Traffic Server to either accept or reject records that satisfy the filter condition.
Required: ACCEPT or REJECT .

LogObject

The following table lists the LogObject specifications.

Field

Allowed Inputs

<Format = "valid_format_name"/>

Required. Valid format names include the predefined logging formats: squid, common, extended, and extended2, as well as any previously-defined custom log formats. There is no default for this tag.

<Filename = "file_name"/>

Required. The filename to which the given log file is written on the local file system or on a remote collation server. No local log file will be created if you fail to specify this tag. All filenames are relative to the default logging directory.

If the name does not contain an extension (for example, squid), then the extension .log is automatically appended to it for ASCII logs and .blog for binary logs (refer to Mode = "valid_logging_mode").
If you do not want an extension to be added, then end the filename with a single (.) dot (for example: squid. ).

<Mode = "valid_logging_mode"/>

Valid logging modes include ascii , binary , and ascii_pipe . The default is ascii .

  • - Use ascii to create event log files in human-readable form (plain ASCII).
  • - Use binary to create event log files in binary format. Binary log files generate lower system overhead and occupy less space on the disk (depending on the information being logged). You must use the logcat utility to translate binary log files to ASCII format before you can read them.
  • - Use ascii_pipe to write log entries to a UNIX named pipe (a buffer in memory). Other processes can then read the data using standard I/O functions. The advantage of using this option is that Traffic Server does not have to write to disk, which frees disk space and bandwidth for other tasks. In addition, writing to a pipe does not stop when logging space is exhausted because the pipe does not use disk space.

If you are using a collation server, then the log is written to a pipe on the collation server. A local pipe is created even before a transaction is processed, so you can see the pipe right after Traffic Server starts. Pipes on a collation server, however, are created when Traffic Server starts.

<Filters = "list_of_valid_filter_names"/>

A comma-separated list of names of any previously-defined log filters. If more than one filter is specified, then all filters must accept a record for the record to be logged.

<Protocols = "list_of_valid_protocols"/>

A comma-separated list of the protocols this object should log. Valid protocol names for this release are HTTP (FTP is deprecated).

<ServerHosts = "list_of_valid_servers"/>

A comma-separated list of valid hostnames.This tag indicates that only entries from the named servers will be included in the file.

<CollationHosts = "list_of_valid_hostnames"/>

A comma-separated list of collation servers to which all log entries (for this object) are forwarded. Collation servers can be specified by name or IP address. Specify the collation port with a colon after the name; for example, host:port .

<Header = "header"/>

The header text you want the log files to contain. The header text appears at the beginning of the log file, just before the first record.

<RollingEnabled = "truth value"/>

Enables or disables log file rolling for the LogObject. This setting overrides the value for the proxy.config.log2.rolling_enabled variable in the records.config file. Set truth value to one of the following values:

0 to disable rolling for this particular LogObject.
1 to roll log files at specific intervals during the day (you specify time intervals with the RollingIntervalSec and RollingOffsetHr fields).
2 to roll log files when they reach a certain size (you specify the size with the RollingSizeMb field).
3 to roll log files at specific intervals during the day or when they reach a certain size (whichever occurs first).
4 to roll log files at specific intervals during the day when log files reach a specific size (at a specified time if the file is of the specified size).

<RollingIntervalSec = "seconds"/>

The seconds between log file rolling for the LogObject; enables you to specify different rolling intervals for different LogObjects.
This setting overrides the value for proxy.config.log2.rolling_interval_sec in the records.config file.

<RollingOffsetHr = "hour"/>

Specifies an hour (from 0 to 23) at which rolling is guaranteed to align. Rolling might start before then, but a rolled file will be produced only at that time. The impact of this setting is only noticeable if the rolling interval is larger than one hour.
This setting overrides the configuration setting for proxy.config.log2.rolling_offset_hr in the records.config file.

<RollingSizeMb = "size_in_MB"/>

The size at which log files are rolled.

Examples

The following is an example of a LogFormat specification that collects information using three common fields:

     <LogFormat>
         <Name = "minimal"/> 
         <Format = "%<chi> : %<cqu> : %<pssc>"/>
     </LogFormat>

The following is an example of a LogFormat specification that uses aggregate operators:

     <LogFormat>
         <Name = "summary"/>
         <Format = "%<LAST(cqts)> : %<COUNT(*)> : %<SUM(psql)>"/>
         <Interval = "10"/>
     </LogFormat> 

The following is an example of a LogFilter that will cause only REFRESH_HIT entries to be logged:

     <LogFilter> 
          <Name = "only_refresh_hits"/>
          <Action = "ACCEPT"/>
          <Condition = "%<pssc> MATCH REFRESH_HIT"/>
</LogFilter>

Note: When specifying the field in the filter condition, you can omit the %<>. This means that the filter below is equivalent to the example directly above:

     <LogFilter>
         <Name = "only_refresh_hits"/>
         <Action = "ACCEPT"/>
         <Condition = "pssc MATCH REFRESH_HIT"/>
     </LogFilter>      

The following is an example of a LogObject specification that creates a local log file for the minimal format defined earlier. The log filename will be minimal.log because this is an ASCII log file (the default).

     <LogObject>
         <Format = "minimal"/>
         <Filename = "minimal"/> 
     </LogObject> 

The following is an example of a LogObject specification that includes only HTTP requests served by hosts in the domain company.com or by the specific server server.somewhere.com. Log entries are sent to port 4000 of the collation host logs.company.com and to port 5000 of the collation host 209.131.52.129.

     <LogObject> 
          <Format = "minimal"/>
          <Filename = "minimal"/>
          <ServerHosts = "company.com,server.somewhere.com"/>
          <Protocols = "http"/>
          <CollationHosts = "logs.company.com:4000,209.131.52.129:5000"/>
     </LogObject>  

>WELF

Traffic Server supports WELF (WebTrends Enhanced Log Format) so you can analyze Traffic Server log files with WebTrends reporting tools. A predefined <LogFormat> that is compatible with WELF is provided at the end of the logs.config file (shown below). To create a WELF format log file, create a <LogObject> that uses this predefined format.

     <LogFormat>
         <Name = "welf"/>
         <Format = "id=firewall time=\"%<cqtd> %<cqtt>\" fw=%<phn> pri=6 
         proto=%<cqus> duration=%<ttmsf> sent=%<psql> rcvd=%<cqhl> 
         src=%<chi> dst=%<shi> dstname=%<shn> user=%<caun> op=%<cqhm> 
         arg=\"%<cqup>\" result=%<pssc> ref=\"%<{Referer}cqh>\" 
         agent=\"%<{user-agent}cqh>\" cache=%<crc>"/>
     </LogFormat>

parent.config

The parent.config file identifies the parent proxies used in an cache hierarchy. Use this file to perform the following configuration:

Traffic Server uses the parent.config file only when the parent caching option is enabled (refer to Configuring Traffic Server to Use a Parent Cache).

IMPORTANT: After you modify the parent.config file, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply your changes. When you apply the changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

Format

Each line in the parent.config file must contain a parent caching rule. Traffic Server recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value

The following table lists the possible primary destinations and their allowed values.

Primary Destination

Allowed Value

dest_domain

A requested domain name.

dest_host

A requested hostname.

dest_ip

A requested IP address or range of IP addresses separated by a dash (-).

url_regex

A regular expression to be found in a URL

The secondary specifiers are optional in the parent.config file. The following table lists the possible secondary specifiers and their allowed values.

Secondary Specifiers

Allowed Value

port

A requested URL port.

scheme

A request URL protocol: http or https.

prefix

A prefix in the path part of a URL.

suffix

A file suffix in the URL.

method

A request URL method. It can be one of the following:
get
post
put
trace

time

A time range, such as 08:00-14:00, during which the parent cache is used to serve requests.

src_ip

A client IP address.

The following tables lists the possible actions and their allowed values.

Action

Allowed Value

parent

An ordered list of parent servers. If the request cannot be handled by the last parent server in the list, then it will be routed to the origin server. You can specify either a hostname or an IP address, but; you must specify the port number.

round_robin

One of the following values:

true - Traffic Server goes through the parent cache list in a round robin-based on client IP address.
strict - Traffic Server machines serve requests strictly in turn. For example: machine proxy1 serves the first request, proxy2 serves the second request, and so on.
false - Round robin selection does not occur.

go_direct

One of the following values:

true - requests bypass parent hierarchies and go directly to the origin server.
false - requests do not bypass parent hierarchies.

Examples

The following rule configures a parent cache hierarchy consisting of Traffic Server (which is the child) and two parents, p1.x.com and p2.x.com. Traffic Server forwards the requests it cannot serve to the parent servers p1.x.com and p2.x.com in a round-robin fashion because:
round_robin=true.
dest_domain=. method=get parent=”p1.x.com:8080; p2.y.com:8080” round_robin=true

The following rule configures Traffic Server to route all requests containing the regular expression politics and the path /viewpoint directly to the origin server (bypassing any parent hierarchies):
url_regex=politics prefix=/viewpoint go_direct=true

Every line in the parent.config file must contain either a parent= or go_direct= directive.

partition.config

The partition.config file enables you to manage your cache space more efficiently and restrict disk usage by creating cache partitions of different sizes for specific protocols. You can further configure these partitions to store data from certain origin servers and/or domains in the hosting.config file.

IMPORTANT: The partition configuration must be the same on all nodes in a cluster. You must stop Traffic Server before you change the cache partition size and protocol assignment. For step-by-step instructions about partitioning the cache, refer to Partitioning the Cache.

Format

For each partition you want to create, enter a line with the following format:
partition=partition_number scheme=protocol_type size=partition_size

where partition_number is a number between 1 and 255 (the maximum number of partitions is 255) and protocol_type is http. Traffic Server supports http for HTTP partition types; partition_size is the amount of cache space allocated to the partition. This value can be either a percentage of the total cache space or an absolute value. The absolute value must be a multiple of 128 MB, where 128 MB is the smallest value. If you specify a percentage, then the size is rounded down to the closest multiple of 128 MB.

Each partition is striped across several disks to achieve parallel I/O. For example: if there are four disks, then a 1-GB partition will have 256 MB on each disk (assuming each disk has enough free space available). If you do not allocate all the disk space in the cache, then the extra disk space is not used. You can use the extra space later to create new partitions without deleting and clearing the existing partitions.

Examples

The following example partitions the cache evenly between HTTP and HTTPS requests:

partition=1 scheme=http size=50%
partition=2 scheme=https size=50%

records.config

The records.config file is a list of configurable variables used by the Traffic Server software. Many of the variables in the records.config file are set automatically when you set configuration options in Traffic Line or Traffic Shell. After you modify the records.config file, navigate to the Traffic Server bin directory and run the command traffic_line -x to apply the changes. When you apply changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

Format

Each variable has the following format:
CONFIG variable_name DATATYPE variable_value

where DATATYPE is INT (integer), STRING (string), or FLOAT (floating point).

Examples

In the following example, the variable proxy.config.proxy_name is a STRING datatype with the value my_server. This means that the name of the Traffic Server proxy is my_server.
CONFIG proxy.config.proxy_name STRING my_server

In the following example, the variable proxy.config.arm.enabled is a yes/no flag. A value of 0 (zero) disables the option; a value of 1 enables the option.
CONFIG proxy.config.arm.enabled INT 0

In the following example, the variable sets the cluster startup timeout to 10 seconds.
CONFIG proxy.config.cluster.startup_timeout INT 10

Configuration Variables

The following table describes the configuration variables listed in the records.config file.

Configuration Variable
Data Type

Default Value

Description

System Variables

proxy.config.proxy_name

STRING

The name of the Traffic Server node.

proxy.config.bin_path

STRING

bin

The location of the Traffic Server bin directory.

proxy.config.proxy_binary

STRING

traffic_server

The name of the executable that runs the traffic_server process.

proxy.config.proxy_binary_opts

STRING

-M

The command-line options for starting Traffic Server.

proxy.config.manager_binary

STRING

traffic_manager

The name of the executable that runs the traffic_manager process.

proxy.config.cli_binary

STRING

traffic_line

 

The name of the executable that runs the command-line interface (Traffic Line).

proxy.config.watch_script

STRING

traffic_cop

The name of the executable that runs the traffic_cop process.

proxy.config.env_prep

STRING

example_prep.sh

 

The script executed before the traffic_manager process spawns the traffic_server process.

proxy.config.config_dir

STRING

config

The directory that contains Traffic Server configuration files.

proxy.config.temp_dir

STRING

/tmp

The directory used for Traffic Server temporary files.

proxy.config.alarm_email

STRING

 

The email address to which Traffic Server sends alarm messages.

During a custom Traffic Server installation, you can specify the email address; otherwise, Traffic Server uses the Traffic Server user account name as the default value for this variable.

proxy.config.syslog_facility

STRING

LOG_DAEMON

The facility used to record system log files.

Refer to Understanding Traffic Server Log Files.

proxy.config.cop.core_signal

INT

0

The signal sent to traffic_cop's managed processes to stop them.

0 = no signal is sent.

proxy.config.cop.linux_min_swapfree_kb

INT

10240

The minimum amount of free swap space allowed before Traffic Server stops the traffic_server and traffic_manager processes to prevent the system from hanging.

This configuration variable applies if swap is enabled in Linux 2.2 only.

proxy.config.cop.linux_min_memfree_kb

INT

10240

The minimum amount of free memory allowed before Traffic Server stops the traffic_server and traffic_manager processes to prevent the system from hanging.

This configuration variable applies if swap is disabled in Linux 2.2 only.

proxy.config.output.logfile

STRING

traffic.out

The name and location of the file that contains warnings, status messages, and error messages produced by the Traffic Server processes.

If no path is specified, then Traffic Server creates the file in its logging directory.

proxy.config.snapshot_dir

STRING

snapshots

The directory in which Traffic Server stores configuration snapshots on the local system. Unless you specify an absolute path, this directory is located in the Traffic Server config directory.

proxy.config.accept_threads

INT

0 When enabled (1), runs a separate thread for accept processing. If disabled (0), then only 1 thread can be created.

proxy.config.thread.default.stacksize

INT

1096908 The new default thread stack size, for all threads. The original default is set at 1 MB.
Local Manager

proxy.config.lm.sem_id

INT

11452

The semaphore ID for the local manager.

proxy.local.cluster.type

INT

3

Sets the clustering mode:

1 = full-clustering mode
2 = management-only mode
3 = no clustering

proxy.config.cluster.rsport

INT

8088

The reliable service port. The reliable service port is used to send configuration information between the nodes in a cluster. All nodes in a cluster must use the same reliable service port.

proxy.config.admin.autoconf_port

INT

8083

The autoconfiguration port.

proxy.config.admin.overseer_port

INT

8082

The port used for retrieving and setting statistics and configuration variables.

proxy.config.admin.number_config_bak

INT

3

The maximum number of copies of rolled configuration files to keep.

proxy.config.admin.user_id

STRING

nobody

Option used to specify who to run the traffic_server process as; also used to specify ownership of config and log files.

The nonprivileged user account designated to Traffic Server.

Process Manager

proxy.config.process_manager.mgmt_port

INT

8084

The port used for internal communication between the traffic_manager and traffic_server processes.

Alarm Configuration

proxy.config.alarm.bin

STRING

example_alarm_bin.sh

Name of the script file that can execute certain actions when an alarm is signaled. The default file is a sample script named example_alarm_bin.sh located in the bin directory. You must edit the script to suit your needs.

proxy.config.alarm.abs_path

STRING

NULL

The full path to the script file that sends email to alert someone about Traffic Server problems.

Authentication Basic Realm

proxy.config.proxy.authenticate.basic.realm

NULL

The authentication realm name. If the default of NULL is specified, then traffic_edge is used.

HTTP Engine

proxy.config.http.server_port

INT

8080

The port that Traffic Server uses when acting as a web proxy server for web traffic.

proxy.config.http.server_port_attr

STRING

X

The server port options. You can specify one of the following:

C=SERVER_PORT_COMPRESSED
X=SERVER_PORT_DEFAULT
T=SERVER_PORT_BLIND_TUNNEL

proxy.config.http.server_other_ports

STRING

NULL

The ports other than the port specified by the variable proxy.config.http.server_port to bind for incoming HTTP requests.

proxy.config.http.ssl_ports

STRING

443 563

The range of ports used for tunneling. Traffic Server allows tunnels only to the specified ports.

For example: to retrieve an object using HTTPS via Traffic Server, a tunnel must be established to an origin server via Traffic Server.

proxy.config.http.insert_request_via_str

INT

1

You can specify one of the following:

0 = no extra information is added to the string.
1 = all extra information is added.
2 = some extra information is added.

proxy.config.http.insert_response_via_str

INT

1

You can specify one of the following:

0 = no extra information is added to the string.
1 = all extra information is added.
2 = some extra information is added.

proxy.config.http.enable_url_expandomatic

INT

1

Enables (1) or disables (0) .com domain expansion. This configures the Traffic Server to resolve unqualified hostnames by prepending with www. and appending with .com before redirecting to the expanded address.

For example: if a client makes a request to host , then Traffic Server redirects the request to www.host.com .

proxy.config.http.no_dns_just_forward_to_parent

INT

0

When enabled (1) and if parent caching is enabled, then Traffic Server does not perform DNS lookups on request hostnames.

proxy.config.http.uncacheable_requests_bypass_parent

INT

1

When enabled (1), Traffic Server bypasses the parent proxy for a request that is not cacheable.

proxy.config.http.keep_alive_enabled

INT

1

Enables (1) or disables (0) the use of keep-alive connections to either origin servers or clients.

proxy.config.http.chunking_enabled

INT

0

Specifies whether Traffic Sever can generate a chunked response:

0 = Never
1 = Always
2 = Generate a chunked response if the server has returned HTTP 1.1 before
3 = Generate a chunked response if the client request is HTTP 1.1 and the origin server has returned HTTP 1.1 before

proxy.config.http.send_http11_requests

INT

3

Configures Traffic Server to use HTTP Version 1.1 when communicating with origin servers. You can specify one of the following values:

1 = Traffic Server always uses HTTP 1.1 when communicating with origin servers.
2 = Traffic Server uses HTTP 1.1 if the origin server has previously used HTTP 1.1.
3 = Traffic Server uses HTTP 1.1 if the client request is HTTP 1.1 and the origin server has previously used HTTP 1.1.

Note: If HTTP 1.1 is used, then Traffic Server can use keep-alive connections with pipelining to origin servers. If HTTP 0.9 is used, then Traffic Server does not use keep-alive connections to origin servers. If HTTP 1.0 is used, then Traffic Server can use keep-alive connections without pipelining to origin servers.

proxy.config.http.share_server_sessions

INT

1

Enables (1) or disables (0) the reuse of server sessions.

proxy.config.http.record_heartbeat

INT

0

Enables (1) or disables (0) traffic_cop heartbeat logging.

Parent Proxy Configuration

proxy.config.http.parent_proxy_routing_enable

INT

0

Enables (1) or disables (0) the parent caching option.

Refer to Hierarchical Caching.

proxy.config.http.parent_proxy.retry_time

INT

300

The amount of time allowed between connection retries to a parent cache that is unavailable.

proxy.config.http.parent_proxy.fail_threshold

INT

10

The number of times the connection to the parent cache can fail before Traffic Server considers the parent unavailable.

proxy.config.http.parent_proxy.total_connect_attempts

INT

4

The total number of connection attempts allowed to a parent cache before Traffic Server bypasses the parent or fails the request (depending on the go_direct option in the bypass.config file).

proxy.config.http.parent_proxy.per_parent_connect_attempts

INT

2

The total number of connection attempts allowed per parent, if multiple parents are used.

proxy.config.http.parent_proxy.connect_attempts_timeout

INT

30

The timeout value (in seconds) for parent cache connection attempts.

proxy.config.http.forward.proxy_auth_to_parent

INT

0

Configures Traffic Server to send proxy authentication headers on to the parent cache.

HTTP Connection Timeouts (secs)

proxy.config.http.keep_alive_no_activity_timeout_in

INT

10

Specifies how long Traffic Server keeps connections to clients open for a subsequent request after a transaction ends.

proxy.config.http.keep_alive_no_activity_timeout_out

INT

10

Specifies how long Traffic Server keeps connections to origin servers open for a subsequent transfer of data after a transaction ends.

proxy.config.http.transaction_no_activity_timeout_in

INT

120

Specifies how long Traffic Server keeps connections to clients open if a transaction stalls.

proxy.config.http.transaction_no_activity_timeout_out

INT

120

Specifies how long Traffic Server keeps connections to origin servers open if the transaction stalls.

proxy.config.http.transaction_active_timeout_in

INT

0

The maximum amount of time Traffic Server can remain connected to a client. If the transfer to the client is not complete before this timeout expires, then Traffic Server closes the connection.

The default value of 0 specifies that there is no timeout.

proxy.config.http.transaction_active_timeout_out

INT

0

The maximum amount of time Traffic Server waits for fulfillment of a connection request to an origin server. If Traffic Server does not complete the transfer to the origin server before this timeout expires, then Traffic Server terminates the connection request.

The default value of 0 specifies that there is no timeout.

proxy.config.http.accept_no_activity_timeout

INT

120

The timeout interval in seconds before Traffic Server closes a connection that has no activity.

proxy.config.http.background_fill_active_timeout

INT

60

Specifies how long Traffic Server continues a background fill before giving up and dropping the origin server connection.

proxy.config.http.background_fill_completed_threshold

FLOAT

0.50000

The proportion of total document size already transferred when a client aborts at which the proxy continues fetching the document from the origin server to get it into the cache (a background fill).

Origin Server Connect Attempts

proxy.config.http.connect_attempts_max_retries

INT

6

The maximum number of connection retries Traffic Server can make when the origin server is not responding.

proxy.config.http.connect_attempts_max_retries_dead_server

INT

2

The maximum number of connection retries Traffic Server can make when the origin server is unavailable.

proxy.config.http.server_max_connections

INT

0

Limits the number of socket connections across all origin servers to the value specified.

To disable, set to zero (0).

proxy.config.http.origin_max_connections

INT

0

Limits the number of socket connections per origin server to the value specified.

To disable, set to zero (0).

proxy.config.http.connect_attempts_rr_retries

INT

2 The maximum number of failed connection attempts allowed before a round-robin entry is marked as 'down' if a server has round-robin DNS entries.

proxy.config.http.connect_attempts_timeout

INT

30

The timeout value (in seconds) for an origin server connection.

proxy.config.http.post_connect_attempts_timeout

INT

1800

The timeout value (in seconds) for an origin server connection when the client request is a POST or PUT request.

proxy.config.http.down_server.cache_time

INT

900

Specifies how long (in seconds) Traffic Server remembers that an origin server was unreachable.

proxy.config.http.down_server.abort_threshold

INT

10

The number of seconds before Traffic Server marks an origin server as unavailable after a client abandons a request because the origin server was too slow in sending the response header.

Congestion Control

proxy.config.http.congestion_control.enabled

INT

0

Enables (1) or disables (0) the Congestion Control option, which configures Traffic Server to stop forwarding HTTP requests to origin servers when they become congested. Traffic Server sends the client a message to retry the congested origin server later.

Refer to Using Congestion Control.

Negative Response Caching

proxy.config.http.negative_caching_enabled

INT

0

When enabled (1), Traffic Server caches negative responses (such as 404 Not Found) when a requested page does not exist. The next time a client requests the same page, Traffic Server serves the negative response directly from cache.

Note: Cache-Control directives from the server forbidding cache are ignored for the following HTTP response codes, regardless of the value specified for the proxy.config.http.negative_caching_enabled variable. The following negative responses are cached by Traffic Server:

204 No Content
305 Use Proxy
400 Bad Request
403 Forbidden
404 Not Found
405 Method Not Allowed
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

proxy.config.http.negative_caching_lifetime

INT

1800

The how long (in seconds) Traffic Server keeps the negative responses valid in cache.

Note: This value only affects negative responses that do have explicit Expires: or Cache-Control: lifetimes set by the server.

Proxy User Variables

proxy.config.http.anonymize_remove_from

INT

0

When enabled (1), Traffic Server removes the From header to protect the privacy of your users.

proxy.config.http.anonymize_remove_referer

INT

0

When enabled (1), Traffic Server removes the Referrer header to protect the privacy of your site and users.

proxy.config.http.anonymize_remove_user_agent

INT

0

When enabled (1), Traffic Server removes the User-agent header to protect the privacy of your site and users.

proxy.config.http.anonymize_remove_cookie

INT

0

When enabled (1), Traffic Server removes the Cookie header to protect the privacy of your site and users.

proxy.config.http.anonymize_remove_client_ip

INT

0

When enabled (1), Traffic Server removes Client-IP headers for more privacy.

proxy.config.http.anonymize_insert_client_ip

INT

1

When enabled (1), Traffic Server inserts Client-IP headers to retain the client IP address.

proxy.config.http.append_xforwards_header

INT

0

When enabled (1), Traffic Server appends X-Forwards headers to outgoing requests.

proxy.config.http.anonymize_other_header_list

STRING

NULL

The headers Traffic Server should remove from outgoing requests.

proxy.config.http.insert_squid_x_forwarded_for

INT

0

When enabled (1), Traffic Server adds the client IP address to the X-Forwarded-For header.

proxy.config.http.normalize_ae_gzip

INT

0

Enable (1) to normalize all Accept-Encoding: headers to one of the following:

  • Accept-Encoding: gzip (if the header has gzip or x-gzip with any q)
    OR
  • blank (for any header that does not include gzip)

This is useful for minimizing cached alternates of documents (e.g. gzip, deflate vs. deflate, gzip). Enabling this option is recommended if your origin servers use no encodings other than gzip.

Security

proxy.config.http.push_method_enabled

INT

0

Enables (1) or disables (0) the HTTP PUSH option, which allows you to deliver content directly to the cache without a user request.

Important: If you enable this option, then you must also specify a filtering rule in the filter.config file to allow only certain machines to push content into the cache.

Cache Control

proxy.config.http.cache.http

INT

1

Enables (1) or disables (0) caching of HTTP requests.

proxy.config.http.cache.ignore_client_no_cache

INT

0

When enabled (1), Traffic Server ignores client requests to bypass the cache.

proxy.config.http.cache.ims_on_client_no_cache

INT

0

When enabled (1), Traffic Server issues a conditional request to the origin server if an incoming request has a No-Cache header.

proxy.config.http.cache.ignore_server_no_cache

INT

0

When enabled (1), Traffic Server ignores origin server requests to bypass the cache.

proxy.config.http.cache.cache_responses_to_cookies

INT

3

Specifies how cookies are cached:

0 = do not cache any responses to cookies
1 = cache for any content-type
2 = cache only for image types
3 = cache for all but text content-types

proxy.config.http.cache.ignore_authentication

INT

0

When enabled (1), Traffic Server ignores WWW-Authentication headers in responses.
WWW-Authentication headers are removed and not cached.

proxy.config.http.cache.cache_urls_that_look_dynamic

INT

0

Enables (1) or disables (0) caching of URLs that look dynamic.

proxy.config.http.cache.enable_default_vary_headers

INT

0

Enables (1) or disables (0) caching of alternate versions of HTTP objects that do not contain the Vary header.

proxy.config.http.cache.when_to_revalidate

INT

0

Specifies when to revalidate content:

0 = use cache directives or heuristic (the default value)
1 = stale if heuristic
2 = always stale (always revalidate)
3 = never stale
4 = use cache directives or heuristic (0) unless the request has an If-Modified-Since header

If the request contains the If-Modified-Since header, then Traffic Server always revalidates the cached content and uses the client's If-Modified-Since header for the proxy request.

proxy.config.http.cache.when_to_add_no_cache_to_msie_requests

INT

0

Specifies when to add no-cache directives to Microsoft Internet Explorer requests. You can specify the following:

0 = no-cache is not added to MSIE requests
1 = no-cache is added to IMS MSIE requests
2 = no-cache is added to all MSIE requests

proxy.config.http.cache.required_headers

INT

0

The type of headers required in a request for the request to be cacheable.

0 = no headers required to make document cacheable
1 = either the Last-Modified header, or an explicit lifetime header, Expires or Cache-Control: max-age, is required
2 = explicit lifetime is required, Expires or Cache-Control: max-age

proxy.config.http.cache.max_stale_age

INT

604800

The maximum age allowed for a stale response before it cannot be cached.

proxy.config.http.cache.range.lookup

INT

1

When enabled (1), Traffic Server looks up range requests in the cache.

proxy.config.http.cache.enable_read_while_writer

INT

0 Enables (1) or disables (0) the ability to read a cached object while another connection is completing a write to cache for the same object. If you want connection collapsing to work, then this option must be enabled.

proxy.config.connection_collapsing.hashtable_enabled

INT

0 Enables (1) or disables (0) whether requests will first search the hashtable to see if another similar request is already being served.

proxy.config.connection_collapsing.rww_wait_time

INT

0 When enabled (1) while the write configuration parameter is also enabled, secondary clients will wait this amount of time (in msec) before cache lookup is retried.

proxy.config.connection_collapsing.revalidate_window_period

INT

0

The amount of time (msec) secondary clients for the same URL will be served the stale object when revalidation of a cached object is in progress.

proxy.config.http.cache.fuzz.min_time

INT

0

Sets a minimum fuzz time; the default value is 0.

Effective fuzz time is a calculation in the range (fuzz.min_time - fuzz.min_time).

proxy.config.http.cache.ignore_accept_mismatch

INT

0 When enabled (1), Traffic Server serves documents from cache with a Content-Type: header that does not match the Accept: header of the request.

Note: This option should only be enabled if you're having problems with caching and one of the following is true:

  • Your origin server sets Vary: Accept when doing content negotiation with Accept
    -OR-
  • The server does not send a 406 (Not Acceptable) response for types that it cannot serve.
  • proxy.config.http.cache.ignore_accept_language_mismatch

    INT

    0

    When enabled (1), Traffic Server serves documents from cache with a Content-Language: header that does not match the Accept-Language: header of the request.

    Note: This option should only be enabled if you're having problems with caching and your origin server is guaranteed to set Vary: Accept-Language when doing content negotiation with Accept-Language.

    proxy.config.http.cache.ignore_accept_encoding_mismatch

    INT

    0

    When enabled (1), Traffic Server serves documents from cache with a Content-Encoding: header that does not match the Accept-Encoding: header of the request.

    Note: This option should only be enabled if you're having problems with caching and your origin server is guaranteed to set Vary: Accept-Encoding when doing content negotiation with Accept-Encoding.

    proxy.config.http.cache.ignore_accept_charset_mismatch

    INT

    0

    When enabled (1), Traffic Server serves documents from cache with a Content-Type: header that does not match the Accept-Charset: header of the request.

    Note: This option should only be enabled if you're having problems with caching and your origin server is guaranteed to set Vary: Accept-Charset when doing content negotiation with Accept-Charset.

    proxy.config.http.cache.ignore_client_cc_max_age

    INT

    1 When enabled (1), Traffic Server ignores any Cache-Control: max-age headers from the client.

    Heuristic Expiration

    proxy.config.http.cache.heuristic_min_lifetime

    INT

    3600

    The minimum amount of time a document in the cache is considered to be fresh.

    proxy.config.http.cache.heuristic_max_lifetime

    INT

    86400

    The maximum amount of time a document in the cache remains fresh.

    proxy.config.http.cache.heuristic_lm_factor

    FLOAT

    0.10000

    The aging factor for freshness computations.

    proxy.config.http.cache.fuzz.time

    INT

    240

    How often Traffic Server checks for an early refresh, during the period before the document stale time. The interval specified must be in seconds.

    proxy.config.http.cache.fuzz.probability

    FLOAT

    0.00500

    The probability that a refresh is made on a document during the specified fuzz time.

    Dynamic Content & Content Negotiation

    proxy.config.http.cache.vary_default_text

    STRING

    NULL

    The header on which Traffic Server varies for text documents.

    For example: if you specify user-agent, then Traffic Server caches all the different user-agent versions of documents it encounters.

    proxy.config.http.cache.vary_default_images

    STRING

    NULL

    The header on which Traffic Server varies for images.

    proxy.config.http.cache.vary_default_other

    STRING

    NULL

    The header on which Traffic Server varies for anything other than text and images.

    Customizable User Response Pages

    proxy.config.body_factory.enable_customizations

    INT

    0

    Specifies whether customizable response pages are enabled or disabled and which response pages are used:

    0 = disable customizable user response pages
    1 = enable customizable user response pages in the default directory only
    2 = enable language-targeted user response pages

    proxy.config.body_factory.enable_logging

    INT

    1

    Enables (1) or disables (0) logging for customizable response pages.
    When enabled, Traffic Server records a message in the error log each time a customized response page is used or modified.

    proxy.config.body_factory.template_sets_dir

    config/body_factory

    The customizable response page default directory.

    proxy.config.body_factory.response_suppression_mode

    INT

    0

    Specifies when Traffic Server suppresses generated response pages:

    0 = never suppress generated response pages
    1 = always suppress generated response pages
    2 = suppress response pages only for intercepted traffic

    DNS

    proxy.config.dns.search_default_domains

    INT

    1

    Enables (1) or disables (0) local domain expansion so that Traffic Server can attempt to resolve unqualified hostnames by expanding to the local domain.

    For example: if a client makes a request to an unqualified host (host_x) and the Traffic Server local domain is y.com , then Traffic Server will expand the hostname to host_x.y.com.

    proxy.config.dns.splitDNS.enabled

    INT

    0

    Enables (1) or disables (0) DNS server selection.
    When enabled, Traffic Server refers to the splitdns.config file for the selection specification.

    Refer to Configuring DNS Server Selection (Split DNS).

    proxy.config.dns.splitdns.def_domain

    STRING

    NULL

    The default domain for split DNS requests. This value is appended automatically to the hostname if it does not include a domain before split DNS determines which DNS server to use.

    proxy.config.dns.url_expansions

    STRING

    NULL

    Specifies a list of hostname extensions that are automatically added to the hostname after a failed lookup.

    For example: if you want Traffic Server to add the hostname extension .org, then specify org as the value for this variable (Traffic Server automatically adds the dot (.).

    Note: If the variable proxy.config.http.enable_url_expandomatic is set to 1 (the default value), then you do not have to add www. and .com to this list because Traffic Server automatically tries www. and .com after trying the values you've specified.

    proxy.config.dns.round_robin_nameservers

    INT

    0

    Enables (1) or disables (0) DNS server round-robin.

    proxy.config.dns.nameservers

    STRING

    NULL

    The DNS servers.

    proxy.config.srv_enabled

    INT

    0 Indicates whether to utilize SRV records for orgin server lookup.

    proxy.config.hostdb.serve_stale_for

    INT

    0 The number of seconds for which to utilize a stale NS record while initiating a background fetch for the new data.

    proxy.config.hostdb.storage_size

    INT

    33554432 The amount of space (in bytes) used to store hostdb. The value of this variable must be increased if you increase the size of the proxy.config.hostdb.size variable.
    HostDB

    proxy.config.hostdb.size

    INT

    200000

    The maximum number of entries allowed in the host database.

    Note: For values above 200000, you must increase the value of the proxy.config.hostdb.storage_size variable by at least 44 bytes per entry.

    proxy.config.hostdb.ttl_mode

    INT

    0

    The host database time to live mode. You can specify one of the following:

    0 = obey
    1 = ignore
    2 = min(X,ttl)
    3 = max(X,ttl)

    proxy.config.hostdb.timeout

    INT

    1440

    The foreground timeout (in minutes).

    proxy.config.hostdb.strict_round_robin

    INT

    0

    When disabled (0), Traffic Server always uses the same origin server for the same client, for as long as the origin server is available.

    Logging Config

    proxy.config.log2.logging_enabled

    INT

    3

    Enables and disables event logging:

    0 = logging disabled
    1 = log errors only
    2 = log transactions only
    3 = full logging (errors + transactions)

    Refer to Working with Log Files.

    proxy.config.log2.max_secs_per_buffer

    INT

    5

    The maximum amount of time before data in the buffer is flushed to disk.

    proxy.config.log2.max_space_mb_for_logs

    INT

    2000

    The amount of space allocated to the logging directory (in MB).

    proxy.config.log2.max_space_mb_for_orphan_logs

    INT

    25

    The amount of space allocated to the logging directory (in MB) if this node is acting as a collation client.

    proxy.config.log2.max_space_mb_headroom

    INT

    10

    The tolerance for the log space limit (in bytes).

    If the variable proxy.config.log2.auto_delete_rolled_file is set to 1 (enabled), then autodeletion of log files is triggered when the amount of free space available in the logging directory is less than the value specified here.

    proxy.config.log2.hostname

    STRING

    localhost

    The hostname of the machine running Traffic Server.

    proxy.config.log2.logfile_dir

    STRING

    install_dir /logs

    The full path to the logging directory.

    proxy.config.log2.logfile_perm

    STRING

    rw-r--r--

    The log file permissions. The standard UNIX file permissions are used (owner, group, other). Permissable values are:

    - no permission
    r read permission
    w write permission
    x execute permission

    Permissions are subject to the umask settings for the Traffic Server process. This means that a umask setting of 002 will not allow write permission for others, even if specified in the configuration file. Permissions for existing log files are not changed when the configuration is changed.

    proxy.config.log2.custom_logs_enabled

    INT

    0

    Enables (1) or disables (0) custom logging.

    proxy.config.log2.xml_logs_config

    INT

    1

    Enables (1) or disables (0) extended custom logging using an XML-based configuration file.
    A value of 0 instructs Traffic Server to use the traditional custom log formats.

    Note: Although Traffic Server supports traditional custom logging, you should use the more versatile XML-based custom formats.

    proxy.config.log2.squid_log_enabled

    INT

    1

    Enables (1) or disables (0) the squid log file format.

    proxy.config.log2.squid_log_is_ascii

    INT

    1

    The squid log file type:

    1 = ASCII
    0 = binary

    proxy.config.log2.squid_log_name

    STRING

    squid

    The squid log filename.

    proxy.config.log2.squid_log_header

    STRING

    NULL

    The squid log file header text.

    proxy.config.log2.common_log_enabled

    INT

    0

    Enables (1) or disables (0) the Netscape common log file format.

    proxy.config.log2.common_log_is_ascii

    INT

    1

    The Netscape common log file type:

    1 = ASCII
    0 = binary

    proxy.config.log2.common_log_name

    STRING

    common

    The Netscape common log filename.

    proxy.config.log2.common_log_header

    STRING

    NULL

    The Netscape common log file header text.

    proxy.config.log2.extended_log_enabled

    INT

    0

    Enables (1) or disables (0) the Netscape extended log file format.

    proxy.confg.log2.extended_log_is_ascii

    INT

    1

    The Netscape extended log file type:

    1 = ASCII
    0 = binary

    proxy.config.log2.extended_log_name

    STRING

    extended

    The Netscape extended log filename.

    proxy.config.log2.extended_log_header

    STRING

    NULL

    The Netscape extended log file header text.

    proxy.config.log2.extended2_log_enabled

    INT

    0

    Enables (1) or disables (0) the Netscape Extended-2 log file format.

    proxy.config.log2.extended2_log_is_ascii

    INT

    1

    The Netscape Extended-2 log file type:

    1 = ASCII
    0 = binary

    proxy.config.log2.extended2_log_name

    STRING

    extended2

    The Netscape Extended-2 log filename.

    proxy.config.log2.extended2_log_header

    STRING

    NULL

    The Netscape Extended-2 log file header text.

    proxy.config.log2.separate_icp_logs

    INT

    0

    When enabled (1), configures Traffic Server to store ICP transactions in a separate log file.

    proxy.config.log2.separate_host_logs

    INT

    0

    When enabled (1), configures Traffic Server to create a separate log file for HTTP transactions for each origin server listed in the log_hosts.config file.

    Refer to HTTP Host Log Splitting.

    proxy.local.log2.collation_mode

    INT

    0

    The log collation mode:

    0 = collation is disabled
    1 = this host is a log collation server
    2 = this host is a collation client and sends entries using standard formats to the collation server
    3 = this host is a collation client and sends entries using the traditional custom formats to the collation server
    4 = this host is a collation client and sends entries that use both the standard and traditional custom formats to the collation server

    For information on sending XML-based custom formats to the collation server, refer to logs_xml.config.

    Note: Although Traffic Server supports traditional custom logging, you should use the more versatile XML-based custom formats.

    proxy.confg.log2.collation_host

    STRING

    NULL

    The hostname of the log collation server.

    proxy.config.log2.collation_port

    INT

    8085

    The port used for communication between the collation server and client.

    proxy.config.log2.collation_secret

    STRING

    foobar

    The password used to validate logging data and prevent the exchange of unauthorized information when a collation server is being used.

    proxy.config.log2.collation_host_tagged

    INT

    0

    When enabled (1), configures Traffic Server to include the hostname of the collation client that generated the log entry in each entry.

    proxy.config.log2.collation_retry_sec

    INT

    5

    The number of seconds between collation server connection retries.

    proxy.config.log2.rolling_enabled

    INT

    1

    Specifies how log files are rolled. You can specify the following values:

    0 = disables log file rolling

    1 = enables log file rolling at specific intervals during the day (specified with the proxy.config.log2.rolling_interval_sec and proxy.config.log2.rolling_offset_hr variables)

    2 = enables log file rolling when log files reach a specific size (specified with the proxy.config.log2.rolling_size_mb variable)

    3 = enables log file rolling at specific intervals during the day or when log files reach a specific size (whichever occurs first)

    4 = enables log file rolling at specific intervals during the day when log files reach a specific size (i.e., at a specified time if the file is of the specified size)

    proxy.config.log2.rolling_interval_sec

    INT

    86400

    The log file rolling interval, in seconds. The minimum value is 300 (5 minutes). The maximum value is 86400 seconds (one day).

    proxy.config.log2.rolling_offset_hr

    INT

    0

    The file rolling offset hour. The hour of the day that starts the log rolling period.

    proxy.config.log2.rolling_size_mb

    INT

    10

    The size that log files must reach before rolling takes place.

    proxy.config.log2.auto_delete_rolled_files

    INT

    1

    Enables (1) or disables (0) automatic deletion of rolled files.

    proxy.config.log2.sampling_frequency

    INT

    1

    Configures Traffic Server to log only a sample of transactions rather than every transaction. You can specify the following values:

    1 = log every transaction
    2 = log every second transaction
    3 = log every third transaction
    and so on...

    proxy.config.http.slow.log.threshold

    INT

    0 The number of milliseconds before a slow connection's debugging stats are dumped.
    Specify 1 to enable or 0 to disable.
    Reverse Proxy

    proxy.config.reverse_proxy.enabled

    INT

    0

    Enables (1) or disables (0) HTTP reverse proxy.

    proxy.config.header.parse.no_host_url_redirect

    STRING

    NULL

    The URL to which to redirect requests with no host headers (reverse proxy).

    URL Remap Rules

    proxy.config.url_remap.default_to_server_pac

    INT

    0

    Enables (1) or disables (0) requests for a PAC file on the proxy service port (8080 by default) to be redirected to the PAC port.

    For this type of redirection to work, the variable proxy.config.reverse_proxy.enabled must be set to 1.

    proxy.config.url_remap.default_to_server_pac_port

    INT

    -1

    Sets the PAC port so that PAC requests made to the Traffic Server proxy service port are redirected this port.

    -1 is the default setting that sets the PAC port to the autoconfiguration port (the default autoconfiguration port is 8083).

    This variable can be used together with the proxy.config.url_remap.default_to_server_pac variable to get a PAC file from a different port. You must create and run a process that serves a PAC file on this port.

    For example: if you create a Perl script that listens on port 9000 and writes a PAC file in response to any request, then you can set this variable to 9000. Browsers that request the PAC file from a proxy server on port 8080 will get the PAC file served by the Perl script.

    proxy.config.url_remap.remap_required

    INT

    1

    Set this variable to 1 if you want Traffic Server to serve requests only from origin servers listed in the mapping rules of the remap.config file. If a request does not match, then the browser will receive an error.

    proxy.config.url_remap.pristine_host_hdr

    INT

    0

    Set this variable to 1 if you want to retain the client host header in a request during remapping.

    SSL Termination

    proxy.config.ssl.accelerator_required

    INT

    0

    Indicates if an accelerator card is required for operation. Traffic Server supports Cavium accelerator cards.

    You can specify:
    0 - not required
    1 - accelerator card is required and Traffic Server will not enable SSL unless an accelerator card is present.
    2 - accelerator card is required and Traffic Server will not start unless an accelerator card is present.

    You can verify operation by running /home/y/bin/openssl_accelerated
    (this comes as part of openssl_engines_init).

    proxy.config.ssl.enabled

    INT

    0

    Enables (1) or disables (0) the SSL Termination option.

    proxy.config.ssl.SSLv2

    INT

    1

    Enables (1) or disables (0) SSLv2.

    proxy.config.ssl.SSLv3

    INT

    1

    Enables (1) or disables (0) SSLv3.

    proxy.config.ssl.TLSv1

    INT

    1

    Enables (1) or disables (0) TLSv1.

    Note: IBM web servers do not support the TLS (Transport Layer Security) protocol. For IBM web servers to work with Traffic Server, you must set this variable to 0.

    proxy.confg.ssl.accelerator.type

    INT

    0

    Specifies if the Cavium SSL accelerator card is installed on (and required by) your Traffic Server machine:

    0 = none (no SSL accelerator card is installed on the Traffic Server machine, so the Traffic Server's CPU determines the number of requests served per second)

    1 = accelerator card is present and required by Traffic Server

    proxy.config.ssl.server_port

    INT

    443

    The port used for SSL communication.

    proxy.config.ssl.client.certification_level

    INT

    0

    Sets the client certification level:

    0 = no client certificates are required. Traffic Server does not verify client certificates during the SSL handshake. Access to Traffic Server depends on Traffic Server configuration options (such as access control lists).

    1 = client certificates are optional. If a client has a certificate, then the certificate is validated. If the client does not have a certificate, then the client is still allowed access to Traffic Server unless access is denied through other Traffic Server configuration options.

    2 = client certificates are required. The client must be authenticated during the SSL handshake. Clients without a certificate are not allowed to access Traffic Server.

    proxy.config.ssl.server.cert.filename

    STRING

    server.pem

    The filename of the Traffic Server SSL certificate (the server certificate).

    proxy.config.ssl.server.cert_chain.filename

    STRING

    NULL

    The file, in a chain of certificates, that is the root certificate recognized by your website.

    proxy.config.ssl.server.cert.path

    STRING

    /config

    The location of the Traffic Server SSL certificate (the server certificate).

    proxy.config.ssl.server.private_key.filename

    STRING

    NULL

    The filename of the Traffic Server private key.

    Change this variable only if the private key is not located in the Traffic Server SSL certificate file.

    proxy.config.ssl.server.private_key.path

    STRING

    NULL

    The location of the Traffic Server private key.

    Change this variable only if the private key is not located in the SSL certificate file.

    proxy.config.ssl.CA.cert.filename

    STRING

    NULL

    The filename of the certificate authority that client certificates will be verified against.

    proxy.config.ssl.CA.cert.path

    STRING

    NULL

    The location of the certificate authority file that client certificates will be verified against.

    Client-Related Configuration

    proxy.config.ssl.client.verify.server

    INT

    0

    Configures Traffic Server to verify the origin server certificate with the Certificate Authority (CA).

    proxy.config.ssl.client.cert.filename

    STRING

    NULL

    The filename of SSL client certificate installed on Traffic Server.

    proxy.config.ssl.client.cert.path

    STRING

    /config

    The location of the SSL client certificate installed on Traffic Server.

    proxy.config.ssl.client.private_key.filename

    STRING

    NULL

    The filename of the Traffic Server private key.

    Change this variable only if the private key is not located in the Traffic Server SSL client certificate file.

    proxy.config.ssl.client.private_key.path

    STRING

    NULL

    The location of the Traffic Server private key.

    Change this variable only if the private key is not located in the SSL client certificate file.

    proxy.config.ssl.client.CA.cert.filename

    STRING

    NULL

    The filename of the certificate authority against which the origin server will be verified.

    proxy.config.ssl.client.CA.cert.path

    STRING

    NULL

    Specifies the location of the certificate authority file against which the origin server will be verified.

    ICP Configuration

    proxy.config.icp.enabled

    INT

    0

    Sets ICP mode for hierarchical caching:

    0 = disables ICP
    1 = allows Traffic Server to receive ICP queries only
    2 = allows Traffic Server to send and receive ICP queries

    Refer to ICP Peering.

    proxy.config.icp.icp_interface

    STRING

    your_interface

    Specifies the network interface used for ICP traffic.

    Note: The Traffic Server installation script detects your network interface and sets this variable appropriately. If your system has multiple network interfaces, check that this variable specifies the correct interface.

    proxy.config.icp.icp_port

    INT

    3130

    Specifies the UDP port that you want to use for ICP messages.

    proxy.config.icp.query_timeout

    INT

    2

    Specifies the timeout used for ICP queries.

    Scheduled Update Configuration

    proxy.config.update.enabled

    INT

    0

    Enables (1) or disables (0) the Scheduled Update option.

    proxy.config.update.force

    INT

    0

    Enables (1) or disables (0) a force immediate update. When enabled, Traffic Server overrides the scheduling expiration time for all scheduled update entries and initiates updates until this option is disabled.

    proxy.config.update.retry_count

    INT

    10

    Specifies the number of times Traffic Server can retry the scheduled update of a URL in the event of failure.

    proxy.config.update.retry_interval

    INT

    2

    Specifies the delay (in seconds) between each scheduled update retry for a URL in the event of failure.

    proxy.config.update.concurrent_updates

    INT

    100

    Specifies the maximum simultaneous update requests allowed at any time. This option prevents the scheduled update process from overburdening the host.

    Remap Plugin Processor

    proxy.config.remap.use_remap_processor

    INT

    0

    Enables (1) or disables (0) the ability to run separate threads for remap plugin processing.

    proxy.config.remap.num_remap_threads

    INT

    1

    Specifies the number of threads that will be used for remap plugin processing.

    Plug-in Configuration

    proxy.config.plugin.plugin_dir

    STRING

    config/plugins

    Specifies the location of Traffic Server plugins.

    Sockets

    proxy.config.net.sock_send_buffer_size_in

    INT

    0

    Sets the send buffer size for connections from the client to Traffic Server.

    proxy.config.net.sock_recv_buffer_size_in

    INT

    0 Sets the receive buffer size for connections from the client to Traffic Server.

    proxy.config.net.sock_option_flag_in

    INT

    0

    Turns different options "on" for the socket handling client connections:

    TCP_NODELAY (1)
    SO_KEEPALIVE (2)

    Note: This is a flag and you look at the bits set. Therefore, you must set the value to 3 if you want to enable both options above.

    proxy.config.net.sock_send_buffer_size_out

    INT

    0 Sets the send buffer size for connections from Traffic Server to the origin server.

    proxy.config.net.sock_recv_buffer_size_out

    INT

    0 Sets the receive buffer size for connections from Traffic Server to the origin server.

    proxy.config.net.sock_option_flag_out

    INT

    0

    Turns different options "on" for the origin server socket:

    TCP_NODELAY (1)
    SO_KEEPALIVE (2)

    Note: This is a flag and you look at the bits set. Therefore, you must set the value to 3 if you want to enable both options above.

    proxy.config.net.sock_mss_in

    INT

    0 Same as the command line option --accept_mss that sets the MSS for all incoming requests.

    remap.config

    The remap.config file contains mapping rules that Traffic Server uses to perform the following actions:

    Refer to Reverse Proxy and HTTP Redirects, for information about redirecting HTTP requests and using reverse proxy.

    IMPORTANT: After you modify the remap.config file, navigate to the Traffic Server bin directory; then run the traffic_line -x command to apply the changes. When you apply the changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

    >Format

    Each line in the remap.config file must contain a mapping rule. Traffic Server recognizes three space-delimited fields: type, target, and replacement. The following table describes the format of each field.

    Field

    Description

    type

    Enter one of the following:

    map --translates an incoming request URL to the appropriate origin server URL.

    reverse_map --translates the URL in origin server redirect responses to point to the Traffic Server.

    redirect --redirects HTTP requests permanently without having to contact the origin server. Permanent redirects notify the browser of the URL change (by returning an HTTP status code 301) so that the browser can update bookmarks.

    redirect_temporary --redirects HTTP requests temporarily without having to contact the origin server. Temporary redirects notify the browser of the URL change for the current request only (by returning an HTTP status code 307).

    Note: use the regex_ prefix to indicate that the line has a regular expression.

    target

    Enter the origin ("from") URL. You can enter up to four components:

    scheme :// host : port / path_prefix

    where scheme is http.

    replacement

    Enter the destination ("to") URL. You can enter up to four components:

    scheme://host:port/path_prefix

    where scheme can be http or https.

    Examples

    The following section shows example mapping rules in the remap.config file.

    Reverse Proxy Mapping Rules

    The following example shows a map rule that does not specify a path prefix in the target or replacement:
    map http://www.x.com/ http://server.hoster.com/

    This rule results in the following translations:

    Client Request

    Translated Request

    http://www.x.com/Widgets/index.html

    http://server.hoster.com/Widgets/index.html

    http://www.x.com/cgi/form/submit.sh?arg=true

    http://server.hoster.com/cgi/form/submit.sh?arg=true

    The following example shows a map rule with path prefixes specified in the target:

    map http://www.intranet.y.com/marketing http://marketing.y.com/
    map http://intranet.y.com/sales http://sales.y.com/
    map http://intranet.y.com/engineering http://engineering.y.com/
    map http://intranet.y.com/ http://info.y.com/

    These rules result in the following translations:

    Client Request

    Translated Request

    http://www.y.com/marketing/projects/manhattan/specs.html

    http://marketing.y.com/projects/manhattan/specs.html

    http://www.y.com/stuff/marketing/projects/boston/specs.html

    http://info.y.com/marketing/projects/boston/specs.html

    http://www.y.com/engineering/marketing/requirements.html

    http://engineering.y.com/marketing/requirements.html

    The following example shows that the order of the rules matters:
    map http://www.g.com/ http://external.g.com/
    map http://www.g.com/stuff http://stuff.g.com

    These rules result in the following translation.

    Client Request

    Translated Request

    http://www.g.com/stuff/a.gif

    http://external.g.com/stuff/a.gif

    In the above examples, the second rule is never applied because all URLs that match the second rule also match the first rule. The first rule takes precedence because it appears earlier in the remap.config file.

    The following example shows a mapping with a path prefix specified in the target and replacement:
    map http://www.h.com/a/b http://server.h.com/customers/x/y

    This rule results in the following translation.

    Client Request

    Translated Request

    http://www.h.com/a/b/c/d/doc.html

    http://server.h.com/customers/x/y/c/d/doc.html

    http://www.h.com/a/index.html

    Translation fails

    The following example shows reverse-map rules:
    map http://www.x.com/ http://server.hoster.com/x/
    reverse_map http://server.hoster.com/x/ http://www.x.com/

    These rules result in the following translations.

    Client Request

    Translated Request

    http://www.x.com/Widgets

    http://server.hoster.com/x/Widgets

     

    Client Request

    Origin server Header

    Translated Header

    http://www.x.com/Widgets

    http://server.hoster.com/x/Widgets/

    http://www.x.com/Widgets/

    When acting as a reverse proxy for multiple servers, Traffic Server is unable to route to URLs from older browsers that do not send the Host: header. As a solution, set the variable proxy.config.header.parse.no_host_url_redirect in the records.config file to the URL to which Traffic Server will redirect requests without host headers.

    Redirect Mapping Rules

    The following rule permanently redirects all HTTP requests for www.company.com to www.company2.com:
    redirect http://www.company.com http://www.company2.com

    The following rule temporarily redirects all HTTP requests for www.company1.com to www.company2.com:
    redirect_temporary http://www.company1.com http://www.company2.com

    Regular Expression Support

    Regular expressions can be specified in remapping rules, with the limitations below:

    Examples

    regex_map http://x ([0-9]+).z.com http://real-x$1.z.com
    regex_redirect http://old.(.*).z.com http://new.$1.z.com

    splitdns.config

    The splitdns.config file enables you to specify the DNS server that Traffic Server should use for resolving hosts under specific conditions. For more information, refer to Configuring DNS Server Selection (Split DNS).

    To specify a DNS server, you must supply the following information in each active line within the file:

    You can also include the following optional information with each DNS server specification:

    IMPORTANT: After you modify the splitdns.config file, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply the changes. When you apply changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

    Format

    Each line in the splitdns.config file uses one of the following formats:
    dest_domain=dest_domain | dest_host | url_regex named=dns_server def_domain=def_domain >search_list=search_list

    The following table describes each field.

    Field

    Allowed Value

    dest_domain

    A valid domain name. This specifies that DNS server selection will be based on the destination domain. You can prefix the domain with an exclamation mark (!) to indicate the NOT logical operator.

    dest_host

    A valid hostname. This specifies that DNS server selection will be based on the destination host. You can prefix the host with an exclamation mark (!) to indicate the NOT logical operator.

    url_regex

    A valid URL regular expression. This specifies that DNS server selection will be based on a regular expression.

    dns_server

    This is a required directive. It identifies the DNS server that Traffic Server should use with the given destination specifier. You can specify a port using a colon (:). If you do not specify a port, then 53 is used. Specify multiple DNS servers with spaces or semicolons (;) as separators.

    You must specify the domains with IP addresses in CIDR ("dot") notation.

    def_domain

    A valid domain name. This optional directive specifies the default domain name to use for resolving hosts. Only one entry is allowed. If you do not provide the default domain, the system determines its value from /etc/resolv.conf

    search_list

    A list of domains separated by spaces or semicolons (;). This specifies the domain search order. If you do not provide the search list, the system determines the value from /etc/resolv.conf

    Examples

    Consider the following DNS server selection specifications:

    dest_domain=internal.company.com named=255.255.255.255:212 255.255.255.254 def_domain=company.com search_list=company.com company1.com

    dest_domain=!internal.company.com named=255.255.255.253

    Now consider the following two requests:

    http://minstar.internal.company.com
    This request matches the first line and therefore selects DNS server 255.255.255.255 on port 212. All resolver requests use company.com as the default domain, and company.com and company1.com as the set of domains to search first.

    http://www.microsoft.com
    This request matches the second line. Therefore, Traffic Server selects DNS server 255.255.255.253. Because no def_domain or search_list was supplied, Traffic Server retrieves this information from /etc/resolv.conf

    ssl_multicert.config

    The ssl_multicert.config file lets you configure Traffic Server to use multiple SSL server certificates with the SSL termination option. If you have a Traffic Server system with more than one IP address assigned to it, then you can assign a different SSL certificate to be served when a client requests a particular IP address.

    Format

    The format of the ssl_multicert.config file is:
    dest_ip=ipaddress ssl_cert_name=cert_name ssl_key_name=key_name

    where ipaddress is an IP address assigned to Traffic Server , cert_name is the filename of the Traffic Server SSL server certificate, and key_name is the filename of the Traffic Server SSL private key. If the private key is located in the certificate file, then you do not need to specify the name of the private key.

    Examples

    The following example configures Traffic Server to use the SSL certificate server.pem for all requests to the IP address 111.11.11.1 and the SSL certificate server1.pem for all requests to the IP address 11.1.1.1. Since the private key is included in the certificate files, no private key name is specified.

    dest_ip=111.11.11.1 ssl_cert_name=server.pem
    dest_ip=11.1.1.1 ssl_cert_name=server1.pem

    The following example configures Traffic Server to use the SSL certificate server.pem and the private key serverKey.pem for all requests to the IP address 111.11.11.1. Traffic Server uses the SSL certificate server1.pem and the private key serverKey1.pem for all requests to the IP address 11.1.1.1.

    dest_ip=111.11.11.1 ssl_cert_name=server.pem ssl_key_name=serverKey.pem
    dest_ip=11.1.1.1 ssl_cert_name=server1.pem ssl_key_name=serverKey1.pem

    storage.config

    The storage.config file lists all the files, directories, and/or hard disk partitions that make up the Traffic Server cache. After you modify the storage.config file, you must restart Traffic Server.

    Format

    The format of the storage.config file is:
    pathname size

    where pathname is the name of a partition, directory or file, and size is the size of the named partition, directory or file (in bytes). You must specify a size for directories or files; size is optional for raw partitions.

    You can use any partition of any size. For best performance:

    Specify pathnames according to your operating system requirements. See the following examples. In the storage.config file, a formatted or raw disk must be at least 128 MB.

    Examples

    The following basic example shows 64 MB of cache storage in the /big_dir directory:
    /big_dir 67108864

    You can use the . symbol for the current directory. Here is an example for 64 MB of cache storage in the current directory:
    . 67108864

    Solaris Example

    The following example is for the Solaris operating system:
    /devices/sbus@1f,0/SUNW,fas@e,880000/sd@2,0:a,raw
    /devices/sbus@1f,0/SUNW,fas@e,880000/sd@2,0:b,raw

    Note: Size is not required because the partitions are raw.

    Linux Example

    The following example is for the Linux operating system:
    /dev/raw_sdb 9105018880

    update.config

    The update.config file controls how Traffic Server performs a scheduled update of specific local cache content. The file contains a list of URLs specifying objects that you want to schedule for update.

    A scheduled update performs a local HTTP GET on the objects at the specific time or interval. You can control the following parameters for each specified object:

    IMPORTANT: After you modify the update.config file, navigate to the Traffic Server bin directory and run the traffic_line -x command to apply changes. When you apply changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.

    Supported Tag/Attribute Pairs

    Scheduled update supports the following tag/attribute pairs when performing recursive URL updates:

    Scheduled update is designed to operate on URL sets consisting of hundreds of input URLs (expanded to thousands when recursive URLs are included); it is not intended to operate on extremely large URL sets, such as those used by Internet crawlers.

    Format

    Each line in the update.config file uses the following format:
    URL\request_headers\offset_hour\interval\recursion_depth\

    The following table describes each field.

    Field

    Allowed Inputs

    URL

    HTTP-based URLs.

    request_headers

    Optional. A list of headers (separated by semicolons) passed in each GET request. You can define any request header that conforms to the HTTP specification. The default is no request header.

    offset_hour

    The base hour used to derive the update periods. The range is 00-23 hours.

    interval

    The interval (in seconds) at which updates should occur, starting at the offset hour.

    recursion_depth

    The depth to which referenced URLs are recursively updated, starting at the given URL. This field applies only to HTTP.

    Examples

    The following example illustrates an HTTP scheduled update:
    http://www.company.com\User-Agent: noname user agent\13\3600\5\

    The example above specifies the URL and request headers, an offset hour of 13 (1 pm), an interval of one hour, and a recursion depth of 5. This would result in updates at 13:00, 14:00, 15:00, and so on. To schedule for an update to occur only once a day, use an interval value of 24 hours x 60 minutes x 60 seconds = 86400.

    Specifying URL Regular Expressions (url_regex)

    This section describes how to specify a url_regex. Entries of type url_regex within the configuration files use regular expressions to perform a match.

    The following table provides examples to show how to create a valid url_regex.

    Value

    Description

    x

    Matches the character x

    .

    Match any character

    ^

    Specifies beginning of line

    $

    Specifies end of line

    [xyz]

    A character class. In this case, the pattern matches either x, y, or z

    [abj-oZ]

    A character class with a range. This pattern matches a, b, any letter from j thru o, or Z

    [^A-Z]

    A negated character class. For example, this pattern matches any character except those in the class.

    r*

    Zero or more r, where r is any regular expression.

    r+

    One or more r, where r is any regular expression.

    r?

    Zero or one r, where r is any regular expression.

    r{2,5}

    From two to five r, where r is any regular expression.

    r{2,}

    Two or more r, where r is any regular expression.

    r{4}

    Exactly four r, where r is any regular expression.

    "[xyz]\"images"

    The literal string [xyz]"images"

    \X

    If X is a, b, f, n, r, t, or v, then the ANSI-C interpretation of \x; otherwise, a literal X. This is used to escape operators such as *

    \0

    A NULL character

    \123

    The character with octal value 123

    \x2a

    The character with hexadecimal value 2a

    (r)

    Matches an r, where r is any regular expression. You can use parentheses to override precedence.

    rs

    The regular expression r, followed by the regular expression s

    r|s

    Either an r or an s

    #<n>#

    Inserts an end node, which causes regular expression matching to stop when reached. The value n is returned.

    You can specify dest_domain=mydomain.com to match any host in mydomain.com. Likewise, you can specify dest_domain=. to match any request.