Varnish is a caching server, and a great one at that, that much we already know. But what about the content you don't want to cache? For example, those shopping cart requests and other completely uncacheable API calls?

We can of course handle it, but we've got to be wary of the sirens of the cargo cult because you will often see something like this on the internet:

sub vcl_backend_response {
    # check if the backend response header named
    # "cache-control" contains the word "private"
    if (beresp.http.cache-control ~ "private") {
        # if so, don't cache by limiting the Time-To-Live
        # period to 0 second
        set beresp.ttl = 0s;
    }
}

This is both pretty intuitive, and also very wrong. In this post, we'll explore why it's a bad idea, how to do better, and along the way, we'll try to shine some light on a couple of lesser known features of Varnish.

As you may know, part of my job consists of helping Varnish users, both customers and community users (join us on IRC!), often looking at their VCL and see if there's anything wrong. And sometimes, there is. After all, VCL is a programming language and mistakes happen. However, one point stands out as being badly understood, and I feel it deserves a short blog post to set the record straight.

The Varnish Configuration Language (VCL) is a small domain-specific language designed to be used to define request handling within Varnish. It is extremely flexible and allows you to let Varnish do exactly whatever you want or need it to do.

With web 2.0 and the growing popularity of social media, websites were put under a lot more stress. Delivering content fast and reliably is a relevant challenge. In the hosting industry (I work at Combell, the leading Belgian web hosting company) we no longer just talk about throwing servers at the problem. Offering fast, stable, secure, scalable and affordable solutions to clients has become the core business.