Getting Started with Varnish Cache

Chapter 3. Varnish Speaks HTTP

Now that we have set up Varnish, it’s time to use it. In Chapter 2 we talked about the configuration settings, so by now you should have the correct networking settings that allow you to receive HTTP requests either directly on port 80 or through another proxy or load balancer.

Out-of-the-box Varnish can already do a lot for you. There is a default behavior that is expressed by the built-in VCL and there are a set of rules that Varnish follows. If your backend application complies with these rules, you’ll have a pretty decent hit rate.

Note

Varnish uses a lot of HTTP best practices to decide what gets cached, how it gets cached, and how long it gets cached. As a web developer, I strongly advise that you apply these best practices in the day-to-day development of your backend applications. This empowers you and helps you avoid having to rely on custom Varnish configurations that suit your application. It keeps the caching logic portable.

Unlike many other proxies, Varnish is an HTTP accelerator. That means Varnish does HTTP and HTTP only. So it makes sense to know HTTP and how it behaves.

There are five ways in which Varnish respects HTTP best practices:

• Idempotence

• State

• Expiration

• Conditional requests

• Cache variations

Let’s have a look at each of these and explore how Varnish deals with them.

Idempotence

Varnish will only cache resources that are requested through an idempotent HTTP verb, which are HTTP verbs that do not change the ...