HTTP Caching
with Varnish

Drupal Mountain Camp, Davos
March 8th, 2024

© David Buchmann

David Buchmann - david@liip.ch

PHP Engineer, Liip AG, Switzerland

But... why?

Response time
Scale with load
Save resources and money

What is a reverse proxy again?

What could possibly go wrong?

Nothing gets cached (HTTP Headers)
Too much gets cached (also HTTP Headers)
Editors see no changes (cache invalidation)
Caches get mixed up (personalized content)

httpstatusdogs.com

Overview

HTTP refresher
HTTP cache control
Varnish
Advanced Topics
Wrap-Up

HTTP Refresher

HTTP: Browser chats with webserver

Request

`1`	`GET /path`

`2`	`Accept-Encoding: text/html`

Response

1HTTP/1.1 200 OK
2Content-Type: text/html
3 
4<html>...</html>

HTTP verbs

GET
HEAD
POST
PUT
DELETE
...

HTTP response codes

1xx hold on
2xx here you go
3xx go away
4xx you fucked up
5xx I fucked up

twitter.com/stevelosh/status/372740571749572610

HTTP Cache Control

Cache control headers

Cache Expiration Model
Cache Validation Model

HTTP 1.1, RFC 2616, Sections 13.2 and 13.3

Cache Expiration

`1`	`Cache-Control: s-maxage=3600, max-age=900`

`2`	`Expires: Sat, 10 Mar 2024 08:00:00 GMT`

s-maxage
max-age
Expires (HTTP 1.0 - avoid!)
Default to default_ttl if nothing specified

max-age

max-age per block and other page elements
Application layer cache for individual elements
Drupal builds the HTTP header from lowest encountered max-age
http_response_header module for rule based HTTP headers (but mostly the Drupal caching framework provides enough tools)

Cache validation

Application specific hash value on response
On request, cheap check if hash changed

ETag: 82901821233 If-None-Match: 82901821233 304 Not Modified

etag

Drupal core sets etag on cacheable responses (using the last modified timestamp)
Drupal handles the If-None-Match header
Drupal redundantly also does Last-Modified and If-Modified-Since

Do not cache

`1`	`Cache-Control: s-maxage=0, private, no-cache`

s-maxage=0: Do not keep in cache
private: For specific user, do not cache on proxies
no-cache: Needs to be validated each time
no-store: May never be placed in cache storage

Surrogate Control

Header specific for your reverse proxy, different from third party caches

`1`	`Cache-Control: no-store`

`2`	`Surrogate-Control: max-age=3600`

Resilience

Response

`1`	`Cache-Control: stale-while-revalidate=3600;`

`2`	`Cache-Control: stale-if-error=3600;`

Request

`1`	`Cache-Control: must-revalidate;`

Default Varnish behaviour

Only attempt to cache GET and HEAD request
Never cache request with cookies / authorization
Never cache response with set-cookie
Only cache safe responses (status 200, 203, 300, 301, 302, 307, 404, 410)

Keep variants apart

Response content depends on request headers

Requests

`1`	`GET /resource`

`2`	`Accept: application/json`

`1`	`GET /resource`

`2`	`Accept: text/xml`

Response

`1`	`Vary: Accept`

Varnish does what you tell it

Think carefully and test thoroughly

Varnish Configuration Language

Read and write header values
If conditions, but no loops
Regular expression and invalidation instructions
No return values, only state changes
No variables, only store information in headers
Varnish modules, Inline C code
//, # and /* foo */ for comments

VCL: Debug time to live

1sub vcl_backend_response {
2    set beresp.http.TTL = beresp.ttl;
3}

VCL: Two applications

01backend default {
02    .host = "127.0.0.1"; .port = "8080";}
03backend legacy {
04    .host = "127.0.0.1"; .port = "8000";}
05 
06sub vcl_recv {
07    if (req.url ~ "^/archive/") {
08        set req.backend_hint = legacy;
09    } else {
10        set req.backend_hint = default;
11    }
12}

VCL can do a lot of things

Add, alter and remove headers from request or response
Decide when and how to cache
Rewrite request URLs

But first make your application behave correctly!

Advanced topics

Cache Invalidation
Cache Tagging
Edge Side Includes

Cache Invalidation

There are two hard things in computer science:

Naming things
Cache invalidation
Off by one errors

Cache busting

Very long cache lifetime for assets
Append ?version to asset links
Query string to miss the cache

1<link rel="stylesheet" href="/css/style.css?v1" type="text/css"/>
2...
3<script src="/js/scripts.js?v1"></script>

Explicit cache invalidation

Long cache lifetime on Varnish
Explicitly tell Varnish to invalidate cached URLs
For changes that are not trackable: low lifetime

Invalidation flavors

Purge: URL and all variants
Refresh: forced cache miss, then update cache
Ban: batch invalidation with regular expression
Tagging: batch invalidation based on tags

Communicating invalidation

varnishadm command line tool
Custom VCL and web requests
Messaging: Unknown Varnish instances (cloud)

purge module to invalidate external caches.
Plugin for specific reverse proxies and CDNs varnish_purge

Custom configuration for purge

01acl invalidators {
02    "localhost";
03}
04 
05if (req.method == "PURGE") {
06    if (!client.ip ~ invalidators) {
07        return (synth(405, "Not allowed"));
08    }
09    return (purge);
10}
11 
12...

Custom configuration for refresh

01acl invalidators {
02    "localhost";
03}
04 
05if (req.http.Cache-Control ~ "no-cache"
06    && client.ip ~ invalidators
07) {
08    set req.hash_always_miss = true;
09}
10 
11...

Banning

Regular expression matching
On any request headers, not only path
Too many ban instructions will overload Varnish

01vcl_backend_response {
02    set beresp.http.X-Url = bereq.url;
03    set beresp.http.X-Host = bereq.http.host;
04}
05 
06vcl_recv {
07  if (req.method == "BAN") {
08    if (!client.ip ~ invalidators) {
09      return (synth(405, "Not allowed"));
10    }
11    ban("obj.http.X-Host ~ " + req.http.X-Host
12      + " && obj.http.X-Url ~ " + req.http.X-Url
13    );
14  }
15}

Cache Tagging

xkey vmod
xkey headers for each content item with the id
Custom VCL to invalidate with xkey.purge()

`1`	`$response->withHeader('xkey',` `'node:2 node:44');`

`1`	`xkey.purge(req.http.xkey-purge);`

You can also use BAN, but its much less efficient

Cache Tagging

The purge module can handle cache tags.
The varnish purge module documents tag invalidation with BAN - somebody should contribute xkey documentation ;-)

Edge Side Includes

Use Edge Side Includes

Like server side include, but on Varnish:

Content embeds URLs to fragments
Varnish fetches and caches elements separatly
Individual caching rules per fragment
E.g. only some elements vary on cookie, different TTL, ...

ESI error handling

Resilience and ESI combine
ESI spec esi:try, esi:attempt, esi:except
Not supported by Symfony Cache nor Varnish
Varnish: VCL

Use Edge Side Includes

You could build something with the placeholder mechanism
The Advanced Varnish module provides ESI blocks (among other nice features)
There is an unmaintained ESI module.

Wrap-Up

Take-Aways

Know your HTTP
Varnish is powerful
Varnish is dangerous
KISS VCL!
Make your application behave correctly first
Understand what you do, test what you do

Thank you!

@dbu@phpc.social

Caching lists of content

Element	weight	Element	weight
A	9	D	22
B	8	A	9
C	7	B	8
D	6	C	7
E	5	E	5
F	4	F	4
G	3	G	3
H	2	H	2
I	1	I	1

Element	weight	Element	weight
A	9	A	9
B	8	B	8
C	7	D	6
D	6	E	5
E	5	F	4
F	4	G	3
G	3	H	2
H	2	I	1
I	1

Caching and Sessions

Strategies when Caching with Sessions

Avoid Session, remove when no longer needed
Cache lookup despite cookies
- Prevent caching when specific
- Vary on Cookies header
User Context: Cache by group

HTTP Caching with Varnish

© David Buchmann

David Buchmann - david@liip.ch

PHP Engineer, Liip AG, Switzerland

But... why?

What is a reverse proxy again?

What could possibly go wrong?

Overview

HTTP Refresher

HTTP: Browser chats with webserver

Request

Response

HTTP verbs

HTTP response codes

HTTP Cache Control

Cache control headers

Cache Expiration

max-age

Cache validation

etag

Do not cache

Surrogate Control

Resilience

Response

Request

Default Varnish behaviour

Keep variants apart

Varnish Configuration Language

VCL: Debug time to live

VCL: Two applications

VCL can do a lot of things

Advanced topics

Cache Invalidation

There are two hard things in computer science:

Cache busting

Explicit cache invalidation

Invalidation flavors

Communicating invalidation

Custom configuration for purge

Custom configuration for refresh

Banning

Cache Tagging

Cache Tagging

Edge Side Includes

Use Edge Side Includes

Like server side include, but on Varnish:

ESI error handling

Use Edge Side Includes

Wrap-Up

Take-Aways

Thank you!

@dbu@phpc.social

Caching lists of content

Caching and Sessions

Strategies when Caching with Sessions

HTTP Caching
with Varnish