Varnish Cache update 4.1

Improved Security and Proxy Support Complement Streaming Architecture, Which Cuts Down of Delivery Times for Larger Objects and Decreased Latency When Accessing Content Through Cache Hierarchies

Updates to Varnish Cache 4.1 include:

Proactive security features

  • Support for different kinds of privilege separation methods, collectively described as jails.
  • Ability for Varnish parent process on most systems to drop effective privileges to normal user mode when not doing operations needing special access;
  • Varnish worker child is enabled to run as a separate vcache user;
  • varnishlog, varnishncsa and other Varnish shared log utilities now must be run in a context with varnish group membership.

PROXY protocol support

  • Socket support for PROXY protocol connections has been added whereby PROXY defines a short preamble on the TCP connection where (usually) a SSL/TLS terminating proxy can signal the real client address.
  • The -a startup argument syntax has been expanded to allow for this: $ varnishd -f /etc/varnish/default.vcl -a :6081 -a 127.0.0.1:6086,PROXY.
  • Both PROXY1 and PROXY2 protocols are supported on the resulting listening socket.
  • For connections coming in over a PROXY socket, client.ip and server.ip will contain the addresses given to Varnish in the PROXY header/preamble (the “real” IPs).
  • The new VCL variables remote.ip and local.ip contains the local TCP connection endpoints. On non-PROXY connections these will be identical to client.ip and server.ip.
  • An expected pattern following this is if (std.port(local.ip) == 80) { } in vcl_recv to see if traffic came in over the HTTP listening socket (so a client redirect to HTTPS can be served).

Warm and cold VCL configurations — Traditionally Varnish has had the concept of active and inactive loaded VCLs. Any loaded VCL lead to state being kept, and a separate set of health checks (if configured) were being run against the backends. To avoid the extra state and backend polling, a loaded VCL is now either warm or cold. Runtime state (incl. backend counters) and health checks are not present for cold VCLs. A warm VCL will automatically be set to cold after vcl cool down seconds.

VMOD backends – Before Varnish 4.1, backends could only be declared in native VCL. Varnish 4.0 moved directors from VCL to VMODs, and VMODs can now also create backends. It is possible to both create the same backends as VCL but dynamically, or create backends that don’t necessarily speak HTTP/1 over TCP to fetch resources.

Backend connection timeout – Backend connections will now be closed by Varnish after backend idle timeout seconds of inactivity. Previously they were kept around forever and the backend servers would close the connection without Varnish noticing it. On the next traffic spike needing these extra backend connections, the request would fail, perhaps multiple times, before a working backend connection was found/created.

Varnish Cache is open source, available under a two-clause BSD license. Varnish Software also delivers additional software and support for more advanced users via subscriptions for Varnish Plus, its premium product. See here.

Online resources

You can download Varnish Cache 4.1 here.

Further details on Varnish Cache 4.1 can be found here.

Caching requests by HTTP status code

Sometimes you may want to cache request based on the status code with a different TTL.

Adding the following in the vcl_backend_response will help you in achieving the result:


if (beresp.status == 403 || beresp.status == 404 || beresp.status >= 500)
{
   set beresp.ttl = 60s;
}