Changes in Varnish 5.2¶
Varnish 5.2 is mostly changes under the hood so most varnish installations will be able to upgrade with no modifications.
New VMODs in the standard distribution¶
We have added three new VMODs to the varnish project.
We have added the variables
bereq.hash to VCL,
which contain the hash value computed by Varnish for the current
request, for use in cache lookup. Their data type is BLOB, which
represents opaque data of any length – the new variables contain
the raw binary hashes.
This is the first time that an element of standard VCL has the BLOB type (BLOBs have only been used in third-party VMODs until now). So we have added VMOD blob to facilitate their use. In particular, the VMOD implements binary-to-text encodings, for example so that you can assign the hash to a header as a base64 or hex string. It also provides some other utilities such as getting the length of a BLOB or testing BLOBs for equality.
See VMOD blob - Utilities for the VCL blob type, encoding and decoding.
Before the introduction of
vcl 4.0 there used to be a
instead of a
return(purge) transition. This module works like old-style
VCL purges (which should be used from both
provides more capabilities than regular purges, and lets you know how many
objects were affected.
As long as we have had VMODs, we had an internal vmod called
which was used with
varnishtest to exercise the VMOD related parts of
varnishd. Over time this vmod grew other useful functions for writing
We only distribute
vmod_debug in source releases, because it has some
pretty evil functionality, for instance
We have taken the non-suicidal test-writing goodies out of
vmod_debug and put them into a new
vmod_vtc, to make them
available to people using
varnishtest to test local configurations,
The hottest trick in
vmod_vtc is that VTC-barriers can be
accessed from the VCL code, but there are other conveniences like
workspace manipulations etc.