La plupart des outils de gestion de sites Internet, comme les CMS ou les solutions d’e-commerce peuvent intégrer dans leur architecture logicielle le composant Varnish pour cacher des pages ou des éléments de pages Web.
La gestion du cache Varnish est alors intégrée à l’outil. C’est à dire que l’outil va générer un en-tête du type TTL (expires ou autre) qui va permettre à Varnish d’appliquer la politique de cache de l’outil. Quand les éléments de sites contiennent des hash dans les URLs, généralement les TTL sont très grands (une année, voire plus). A chaque nouvelle version de cet élément l’outil va modifier le hash, et les utilisateurs pourront ainsi récupérer la nouvelle version sans qu’il n’y ait eu de purge de l’ancienne, puisque l’élément a un nouveau nom !
Dans le cas où les éléments ne changent pas de nom, la home page par exemple, ou des pages Web avec des permaliens, c’est l’outil qui va envoyer une requête de purge à Varnish (généralement une requête HTTP de type PURGE), qui va ainsi rafraîchir son cache et envoyer la nouvelle version.
Ces technologies sont relativement bien rodées sauf dans quelques cas où une extension ne gère pas le cache Varnish ou bien quand on insère dans blocs dans une page ou qu’on fait de l’ESI par exemple.
Dans ces cas, on peut toujours rafraîchir le cache Varnish en ligne de commande avec l’outil d’administration varnishadm ou bien en forgeant une requête de type PURGE, mais ces techniques dépassent souvent les permissions accordés aux webmestres ou leur compétences.
Il reste une solution assez simple d’utilisation, c’est de déclencher une purge Varnish quand l’utilisateur demande une version de la page qui ne provient pas du cache, c’est à dire avec le header HTTP « Cache-Control: no-cache »
C’est le header envoyé par les navigateurs quand on demande le rafraîchissement d’une page. Selon les OS et les navigateurs, le rafraîchissement s’obtient par les raccourcis claviers suivants :
- Windows:
Ctrl+F5 - Mac:
Command+Shift+R - Linux:
Ctrl+Shift+R
Dans le livre Varnish 6 by example, il est écrit :
« How Varnish deals with Cache-Control
First things first: Varnish doesn’t respect the Cache-Control as a request header, only as a response header. »
Effectivement l’objectif de Varnish ce n’est pas que les utilisateurs contournent le cache et le vide sans arrêt. L’idée de la mise en place du rafraîchissement par un navigateur, c’est de filtrer les IP qui ont le droit de de procéder au rafraîchissement.
On trouve des articles des années 2010 sur Internet qui indiquent comment faire et qui proposent des élément de configuration des fichiers VCL de Varnish datant de Varnish 3 ou 4 :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
acl CTRLF5 { "127.0.0.1"; } sub vcl_hit { if (client.ip ~ CTRLF5) { if (req.http.pragma ~ "no-cache" || req.http.Cache-Control ~ "no-cache") { set obj.ttl = 0s; return(pass); } else { return(deliver); } } else { return(deliver); } } |
Bref, quand on travaille sur Varnish 6 avec des CDN ou des proxy SSL type Nginx, on ne risque pas de faire fonctionner le rafraîchissement avec le code ci-dessus !
La configuration actualisée pour Varnish 6 serait du type :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
# VCL version 5.0 is not supported so it should be 4.0 even though actually used Varnish version is 6 vcl 4.0; import std; ... # Declaration des IP autorisées à purger les pages purge { "localhost"; "127.0.0.1"; "::1"; "78.201.202.159"; # IP de ma maison "90.63.253.70"; # toHero (Orange) "212.114.18.211"; # toHero (Free) } ... sub vcl_hit { # Comme on est derrière Nginx, client.ip est l'IP du proxy pour tous les clients !!! # Si on se basait sur client.ip, il n'y aurait aucun filtrage... # On utilise X-Real-IP, sauf si la requête provient de localhost if ((req.http.X-Real-IP) && (std.ip(req.http.X-Real-IP) ~ purge) || client.ip ~ purge) { if (req.http.pragma ~ "no-cache" || req.http.Cache-Control ~ "no-cache") { ban("obj.http.X-Req-URL ~ " + req.url); return (restart); } } ... |
Une fois cette configuration installée, on peut procéder à quelques tests !
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
aa2@apollo:~$ curl -s -k -D - -o /dev/null "https://alain.arditi.fr/" HTTP/1.1 200 OK Server: nginx Date: Wed, 22 Feb 2023 14:51:19 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT Vary: Accept-Encoding Age: 24 X-Cache: HIT Accept-Ranges: bytes aa2@apollo:~$ # On force le rafraichissement aa2@apollo:~$ curl -s -k -H "Cache-control: no-cache" -D - -o /dev/null "https://alain.arditi.fr/" HTTP/1.1 200 OK Server: nginx Date: Wed, 22 Feb 2023 14:51:25 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT Vary: Accept-Encoding Age: 0 X-Cache: MISS Accept-Ranges: bytes aa2@apollo:~$ aa2@apollo:~$ curl -s -k -D - -o /dev/null "https://alain.arditi.fr/" HTTP/1.1 200 OK Server: nginx Date: Wed, 22 Feb 2023 15:33:08 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 31761 Connection: keep-alive Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT Vary: Accept-Encoding Age: 14 X-Cache: HIT Accept-Ranges: bytes aa2@apollo:~$ # Test depuis une IP qui n'est pas dans l'access list "purge" : arditi-host3:~# curl -s -k -H "Cache-control: no-cache" -D - -o /dev/null "https://alain.arditi.fr/" HTTP/1.1 200 OK Server: nginx Date: Wed, 22 Feb 2023 15:35:23 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 31761 Connection: keep-alive Last-Modified: Sun, 06 Nov 2022 21:39:44 GMT Vary: Accept-Encoding Age: 149 X-Cache: HIT Accept-Ranges: bytes arditi-host3:~# |
…..