Ubuntu Manpage: VCL - Varnish Configuration Language

Provided by: varnish_5.2.1-1ubuntu0.1_amd64

NAME

       VCL - Varnish Configuration Language

DESCRIPTION

The VCL language is a small domain-specific language designed to be used to describe
request handling and document caching policies for Varnish Cache.

When a new configuration is loaded, the varnishd management process translates the VCL
code to C and compiles it to a shared object which is then loaded into the server process.

This document focuses on the syntax of the VCL language. For a full description of syntax
and semantics, with ample examples, please see the online documentation at
https://www.varnish-cache.org/docs/ .

Starting with Varnish 4.0, each VCL file must start by declaring its version with vcl
<major>.<minor>; marker at the top of the file. See more about this under Versioning
below.

Operators
The following operators are available in VCL:

= Assignment operator.

== Comparison.

~ Match. Can either be used with regular expressions or ACLs.

! Negation.

&& Logical and.

|| Logical or.

Conditionals
VCL has if and else statements. Nested logic can be implemented with the elseif statement
(elsif/elif/else if are equivalent).

Note that there are no loops or iterators of any kind in VCL.

Strings, booleans, time, duration, integers and real numbers
These are the data types in Varnish. You can set or unset these.

Example:

set req.http.User-Agent = "unknown";
unset req.http.Range;

Strings
Basic strings are enclosed in double quotes "...", and may not contain newlines. Long
strings are enclosed in {"..."}. They may contain any character including single double
quotes ", newline and other control characters except for the NUL (0x00) character.

Booleans
Booleans can be either true or false. In addition, in a boolean context some data types
will evaluate to true or false depending on their value.

String types will evaluate to false if they are empty; backend types will evalute to false
if they don't have a backend assigned; integer types will evaluate to false if their value
is zero; duration types will evaluate to false if their value is equal or less than zero.

Time
VCL has time. A duration can be added to a time to make another time. In string context
they return a formatted string in RFC1123 format, e.g. Sun, 06 Nov 1994 08:49:37 GMT.

The keyword now returns a time representing the current time in seconds since the Epoch.

Durations
Durations are defined by a number followed by a unit. The number can include a fractional
part, e.g. 1.5s. The supported units are:

ms milliseconds

s seconds

m minutes

h hours

d days

w weeks

y years

Integers
Certain fields are integers, used as expected. In string context they return a string.

Real numbers
VCL understands real numbers. As with integers, when used in a string context they will
return a string.

Regular Expressions
Varnish uses Perl-compatible regular expressions (PCRE). For a complete description please
see the pcre(3) man page.

To send flags to the PCRE engine, such as to do case insensitive matching, add the flag
within parens following a question mark, like this:

# If host is NOT example dot com..
if (req.http.host !~ "(?i)example\.com$") {
...
}

Include statement
To include a VCL file in another file use the include keyword:

include "foo.vcl";

Import statement
The import statement is used to load Varnish Modules (VMODs.)

Example:

import std;
sub vcl_recv {
std.log("foo");
}

Comments
Single lines of VCL can be commented out using // or #. Multi-line blocks can be commented
out with /*block*/.

Example:

sub vcl_recv {
// Single line of out-commented VCL.
# Another way of commenting out a single line.
/*
Multi-line block of commented-out VCL.
*/
}

Backend definition
A backend declaration creates and initialises a named backend object. A declaration start
with the keyword backend followed by the name of the backend. The actual declaration is in
curly brackets, in a key/value fashion.:

backend name {
.attribute = "value";
}

The only mandatory attribute is .host. The attributes will inherit their defaults from the
global parameters. The following attributes are available:

.host (mandatory)
The host to be used. IP address or a hostname that resolves to a single IP
address.

.port The port on the backend that Varnish should connect to.

.host_header
A host header to add to probes and regular backend requests if they have no such
header.

.connect_timeout
Timeout for connections.

.first_byte_timeout
Timeout for first byte.

.between_bytes_timeout
Timeout between bytes.

.probe Attach a probe to the backend. See Probes

.proxy_header
The PROXY protocol version Varnish should use when connecting to this backend.
Allowed values are 1 and 2.

.max_connections
Maximum number of open connections towards this backend. If Varnish reaches the
maximum Varnish it will start failing connections.

Backends can be used with directors. Please see the vmod_directors(3) man page for more
information.

Probes
Probes will query the backend for status on a regular basis and mark the backend as down
it they fail. A probe is defined as this:

probe name {
.attribute = "value";
}

The probe named default is special and will be used for all backends which do not
explicitly reference a probe.

There are no mandatory options. These are the options you can set:

.url The URL to query. Defaults to /.

.request
Specify a full HTTP request using multiple strings. .request will have \r\n
automatically inserted after every string. If specified, .request will take
precedence over .url.

.expected_response
The expected HTTP response code. Defaults to 200.

.timeout
The timeout for the probe. Default is 2s.

.interval
How often the probe is run. Default is 5s.

.initial
How many of the polls in .window are considered good when Varnish starts.
Defaults to the value of .threshold - 1. In this case, the backend starts as
sick and requires one single poll to be considered healthy.

.window
How many of the latest polls we examine to determine backend health. Defaults
to 8.

.threshold
How many of the polls in .window must have succeeded for us to consider the
backend healthy. Defaults to 3.

Access Control List (ACL)
An Access Control List (ACL) declaration creates and initialises a named access control
list which can later be used to match client addresses:

acl localnetwork {
"localhost"; # myself
"192.0.2.0"/24; # and everyone on the local network
! "192.0.2.23"; # except for the dial-in router
}

If an ACL entry specifies a host name which Varnish is unable to resolve, it will match
any address it is compared to. Consequently, if it is preceded by a negation mark, it will
reject any address it is compared to, which may not be what you intended. If the entry is
enclosed in parentheses, however, it will simply be ignored.

To match an IP address against an ACL, simply use the match operator:

if (client.ip ~ localnetwork) {
return (pipe);
}

VCL objects
A VCL object can be instantiated with the new keyword:

sub vcl_init {
new b = directors.round_robin()
b.add_backend(node1);
}

This is only available in vcl_init.

Subroutines
A subroutine is used to group code for legibility or reusability:

sub pipe_if_local {
if (client.ip ~ localnetwork) {
return (pipe);
}
}

Subroutines in VCL do not take arguments, nor do they return values. The built in
subroutines all have names beginning with vcl_, which is reserved.

To call a subroutine, use the call keyword followed by the subroutine's name:

sub vcl_recv {
call pipe_if_local;
}

Return statements
The ongoing vcl_* subroutine execution ends when a return(<action>) statement is made.

The <action> specifies how execution should proceed. The context defines which actions are
available.

Multiple subroutines
If multiple subroutines with the name of one of the built-in ones are defined, they are
concatenated in the order in which they appear in the source.

The built-in VCL distributed with Varnish will be implicitly concatenated when the VCL is
compiled.

Variables
In VCL you have access to certain variable objects. These contain requests and responses
currently being worked on. What variables are available depends on context.

bereq
bereq
Type: HTTP

Readable from: backend

The entire backend request HTTP data structure

bereq.backend
Type: BACKEND

Readable from: vcl_pipe, backend

Writable from: vcl_pipe, backend

This is the backend or director we attempt to fetch from. When set to a director,
reading this variable returns an actual backend if the director has resolved
immediately, or the director otherwise. When used in string context, returns the name
of the director or backend, respectively.

bereq.between_bytes_timeout
Type: DURATION

Readable from: backend

Writable from: backend

The time in seconds to wait between each received byte from the backend. Not available
in pipe mode.

bereq.body
Type: BODY

Writable from: vcl_backend_fetch

The request body.

bereq.connect_timeout
Type: DURATION

Readable from: vcl_pipe, backend

Writable from: vcl_pipe, backend

The time in seconds to wait for a backend connection.

bereq.first_byte_timeout
Type: DURATION

Readable from: backend

Writable from: backend

The time in seconds to wait for the first byte from the backend. Not available in pipe
mode.

bereq.hash
Type: BLOB

Readable from: vcl_pipe, backend

The hash key of this request.

bereq.http.
Type: HEADER

Readable from: vcl_pipe, backend

Writable from: vcl_pipe, backend

The corresponding HTTP header.

bereq.is_bgfetch
Type: BOOL

Readable from: backend

True for background fetches.

bereq.method
Type: STRING

Readable from: vcl_pipe, backend

Writable from: vcl_pipe, backend

The request type (e.g. "GET", "HEAD").

bereq.proto
Type: STRING

Readable from: vcl_pipe, backend

Writable from: vcl_pipe, backend

The HTTP protocol version used to talk to the server.

bereq.retries
Type: INT

Readable from: backend

A count of how many times this request has been retried.

bereq.uncacheable
Type: BOOL

Readable from: backend

Indicates whether this request is uncacheable due to a pass in the client side or a hit
on an hit-for-pass object.

bereq.url
Type: STRING

Readable from: vcl_pipe, backend

Writable from: vcl_pipe, backend

The requested URL.

bereq.xid
Type: STRING

Readable from: backend

Unique ID of this request.

beresp
beresp
Type: HTTP