It's all about HTTP

It’s all about HTTP

HTTP is not just one of the things we do, it’s the only thing we do.

In this chapter we will talk about HTTP’s built-in caching semantics, and how they allow you to control the behavior of Varnish.

When it comes to configuring Varnish, and customizing the behavior of the cache, the Varnish Configuration Language seems like the best choice. The level of flexibility you get seems unparalleled.

But here’s a statement that might challenge that idea:

Write as little VCL as possible; let HTTP do the heavy lifting.

It looks like we’re undercutting the number one feature of Varnish, but there’s a bit more nuance to the statement:

The HTTP protocol has built-in caching semantics.
These caching mechanisms are both officially specified and widely adopted.
Using the right HTTP response headers, backends can express whether a page can be cached, how, and for how long.
Varnish can automatically parse and act upon those headers, giving more control to the backends.

By leveraging HTTP headers, application developers have a conventional and portable way to control the behavior of the cache. Even if Varnish is swapped out for another caching proxy, the behavior should be the same.

Although you can achieve a lot more by writing VCL, using HTTP can reduce the line count of your VCL file, making it easier to maintain. It also make sense from an architectural point of view to let the backend, which is the content producer, decide how long said content can be cached.

So without further ado, let’s talk about leveraging HTTP.