Section implements a pure and unchanged version of the Varnish Cache.
At every opportunity, the implementation of Varnish Cache on the Section platform has been designed to be as close as possible to how it would be if you had installed Varnish Cache yourself locally.
Section uses the official Varnish Cache distributions published by Varnish Cache. Section does not use custom-compiled builds of Varnish Cache.
Varnish Cache is started, listening on port 80.
Varnish Cache VCL can found in the default.vcl file in the corresponding subdirectory of your Section application repository.
Assuming Varnish Cache is the first proxy in your proxy stack, Varnish Cache will receive connections from the Section TLS Offload Proxy with two additional HTTP request headers.
Issuing cache invalidation requests to Varnish Cache sends a ban command to the Varnish Cache management interface. Section accepts any valid Ban expression and passes it to Varnish Cache unaltered.
We also provide some convenience tools to help with removing particular URL’s from the cache, see our Cache Clearing documentation for more details.
Requesting the Varnish Cache Log executes varnishlog for each Varnish Cache instance and returns the results.
varnishncsa is also running, logging request and response details, including cache effectiveness. This data is used to drive the charts seen in Aperture.
The Varnish Configuration Language (VCL) is a domain-specific language for caching HTTP requests. The language is specific to the domain of caching HTTP requests and responses.
The two most important Varnish states or subroutines or subs are “received request"
vcl_recv and “backend response”
Source: Varnish Software Book
Each HTTP request flows by switching between Varnish Cache states such as
pass by calling
return functions which use VCL logic to determine which state is next. For each state
recv there is a VCL subroutine
|recv||vcl_recv||Received||HTTP request is completely received, parsed and can then be inspected and modified by this routine.
|hash||vcl_hash||Hash||Creates a unique hash key for each cached object. By default, the builtin
|miss||vcl_miss||Miss||If a requested object is not found by a lookup of the cache hash key, it is declared a miss by the
|pass||vcl_pass||Pass||“Called upon entering pass mode. In this mode, the request is passed on to the backend, and the backend’s response is passed on to the client, but is not entered into the cache. Subsequent requests submitted over the same client connection are handled normally”.|
|pipe||vcl_pipe||Pipe||Pipes a HTTP request direct to backend or origin, passing back and forwards with no other VCL running. Basically turns Varnish into a dump TCP/IP proxy.|
|deliver||vcl_deliver||Deliver||Usually the last exit point for HTTP request flows and is often used to add or remove debug-headers. Cached content is ready to be delivered to client of user.|
Varnish Cache modifications or vmods pre-installed on Section. This is a collection of modules (“vmods”) extending Varnish VCL used for describing HTTP request/response policies with additional capabilities.
|cookie||Cookie||HTTP request is received and can then be inspected and modified by this routine.|
|vsthrottle||Throttling VMOD||A Varnish Cache vmod for rate-limiting traffic on a single Varnish Cache server. Offers a simple interface for throttling traffic on a per-key basis to a specific request rate.|
|header||Header VMOD for Varnish Cache||Varnish Cahce Module for manipulation of duplicated HTTP headers, for instance multiple Set-Cookie headers.|
|saintmode||Saint mode backend director||Saintmode lets you deal with a backend that is failing in random ways for specific requests. It maintains a blacklist per backend, marking the backend as sick for specific objects. When the number of objects marked as sick for a backend reaches a set threshold, the backend is considered sick for all requests. Each blacklisted object carries a TTL, which denotes the time it will stay blacklisted.|
|softpurge||Softpurge||Softpurge is cache invalidation in Varnish that reduces TTL but keeps the grace value of a resource. It is not safe to use with Varnish Cache 5.0 onwards, use vmod-purge from Varnish Cache 5.2 instead.|
|tcp||TCP vmod||The TCP vmod opens for access and modification of client TCP connection attributes from VCL.|
|var||var||This VMOD implements basic variable support in VCL.|
|xkey||xkey - Surrogate keys support for Varnish Cache||This vmod adds secondary hashes to objects, allowing fast purging on all objects with this hash key.|
|bodyaccess||Body access||Undocumented VMOD giving access to body objects.|
"Make sure you understand this: Your own VCL-configuration will not overwrite this builtin configuration, it will just be prepended to each sub. Unless your VCL code executes a terminating statement (e.g. return(pass)) it will continue into these default subs.”
Source: Varnish Examples
This document is inspired by Integralist
Varnish Cache 4.1 is available if you need this version
Varnish Cache 4.0 is available if you need this version
If you have a need to run Varnish Cache 3, eg. you have existing v3 VCL you want to run in Section, pick this one. This proxy also has ESI enabled to support the [Magento Turpentine extension]
Varnish is a registered trademark of Varnish Software AB and its affiliates