Comment utiliser le cache Varnish sur un Hébergement Web Gandi¶

Les instances Hébergement Web et les accélérateurs Web bénéficient d’un puissant système de cache alimenté par Varnish. Cela vous permet de distribuer le contenu de votre site internet à un plus grand nombre de visiteurs sans utiliser les ressources de votre instance ou serveur.

Par exemple, lorsqu’un visiteur d’un site internet demande un fichier “foo.jpg” de votre serveur web, ce fichier est placé dans le cache de Varnish. Lorsque le visiteur suivant demande la même image, l’image est servie à partir du cache Varnish (varnish cache server), ainsi votre serveur web sera soulagé et ne répondra à la demande.

Vérifier l’état du cache (cache control)¶

La mise en cache est activée par défaut et une période d’expiration de 120 secondes est définie pour toutes les requêtes.

Vous pouvez contrôler combien de temps un objet doit être mis en cache, ou s’il doit l’être. Vous pouvez également contrôler si différentes représentations d’un même objet doivent être mises en cache pour répondre à différentes options de requête. Pour en savoir plus sur le contrôle du cache, consultez les sections suivantes.

Lorsque vous faites une demande HTTP à un site internet hébergé sur Hébergement Web ou lié à un Web Accelerator, vous remarquerez que la réponse contiendra des en-têtes spécifiques qui indiquent si la mise en cache est activée ou non.

Vous pouvez utiliser une variété d’outils pour voir les en-têtes HTTP dans les réponses. Par exemple, vous pouvez utiliser l’outil « Inspecteur » de votre navigateur ou la commande suivante: curl -i http://example.com

Toutes les requêtes HTTP(s), cachées ou non, passent par notre système de cache Varnish, vous trouverez donc toujours l’en-tête Via (RFC) dans les réponses :

Via: 1.1 varnish

Pour déterminer si votre réponse est mise en cache, vérifiez si l’en-tête Age: a une valeur supérieure à 0. L’exemple suivant montre une réponse qui a été servie à partir du cache et générée par le code actuel il y a 117 secondes :

Via: 1.1 varnish
Age: 117

Faites plusieurs demandes à la même adresse et voyez si la valeur Age: augmente ou reste à 0. Si l’objet n’est pas mis en cache, la valeur sera toujours 0, ce qui signifie qu’il a été servi par l’instance et non par l’Accélérateur Web.

Sinon, la valeur augmentera jusqu’à ce que le cache expire lorsque l’objet est servi par l’Accélérateur Web, ou directement depuis le cache de votre navigateur, ou depuis un système proxy intermédiaire tel que votre FAI ou votre proxy d’entreprise. Après expiration, ou après une purge, la valeur sera 0 pour la première réponse.

Modifier ou désactiver la période de cache¶

La période par défaut pendant laquelle un élément restera dans le cache est de 120 secondes. Si vous souhaitez modifier ceci, vous pouvez le faire en ajoutant l’en-tête suivant et en variant la valeur de max-age (en secondes):

HTTP Cache-Control: max-age=200

Attention

Pour des raisons de développement ou de test, vous pouvez réduire le cache à 1 seconde, avec max-age=1. Avec max-age=0, le cache sera désactivé, mais sachez que les performances de votre instance seront réduites sans le système de cache en place, et n’est pas recommandé.

Par exemple en PHP :

header("Cache-Control: max-age=1");

Un autre exemple depuis un fichier .htaccess si site internet est statique :

Header add Cache-Control "max-age=1"

Exemple dans node. js: (Fonctionne avec les bibliothèques HTTP standard et avec le framework Express )

function (request, response) {
    response.setHeader('Cache-Control', 'max-age=1');
}

Note

Clients VPS avancés : L’accélérateur Web prend en charge s-maxage.

Purge du cache¶

Vous trouverez ci-dessous les différentes méthodes disponibles pour purger les objets de la cache Varnish.

Purge du cache en utilisant la requête HTTP PURGE/PURGEALL¶

Il est possible de purger un cache URL particulier en envoyant une requête HTTP PURGE. Vous pouvez également purger le cache entier avec une requête HTTP PURGEALL.

Note

Les requêtes PURGE et PURGEALL ne fonctionneront qu’à partir de votre Hébergement Web Gandi. Pour le moment, ils ne peuvent pas être émis à distance.

Par exemple, vous pouvez vous connecter à votre instance ou serveur en utilisant la console SSH et exécuter une commande curl:

$ curl -X PURGE http:​//www.example.com/test/index.html
$ curl -X PURGEALL http:​//www.example.com/

Vous pouvez comme alternative utiliser un script PHP tel que celui-ci qui peut-être appelé à partir d’un navigateur pour effacer un cache URL particulier:

<?php
/* purge.php
 * Purge a URL on this host
 */
header("Cache-Control: max-age=1"); // don't cache ourself

error_reporting(E_ALL);
ini_set("display_errors", 1);

// Set to true to hide varnish result
define("SILENT", false);

$path = isset($_GET["path"]) ? $_GET["path"] : "";

$purge_url = "http:​//" . $_SERVER["HTTP_HOST"] . "/$path";

if ( $ch = curl_init($purge_url) ) {
    curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PURGE");
    curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);
    curl_setopt($ch, CURLOPT_NOBODY, SILENT);

    curl_exec($ch);
    curl_close($ch);
}
?>

Purge du cache depuis l’interface web¶

Il est possible de purger le cache directement depuis la page d’administration de votre Hébergement Web Gandi.

Pour ce faire, une fois que vous êtes sur le panneau de contrôle de votre instance, cliquez sur « Se connecter ».

Une fois connecté, trouvez la section « Varnish » et cliquez sur le lien pour purger tous les objets dans le cache.

Si vous voyez « 200 = OK », cela signifie que la purge a réussi.

Note

La commande PURGEALL ne peut-être exécutée que toutes les 120 secondes. Cette limitation a pour but de prévenir l’abus du processeur cache.

Purger le cache lors du déploiement d’une branche git¶

Pour les instances Hébergement Web qui utilisent le dépôt git intégré, l’exécution de la commande de déploiement exécutera automatiquement un PURGEALL à la fin du processus de déploiement.

mod_expires¶

Votre instance inclut le module mod_expires activé dans Apache2, qui vous permet de définir des dates d’expiration personnalisées pour les éléments mis en cache en fonction de l’heure à laquelle le fichier source a été modifié ou de l’heure d’accès du client.

Vous pouvez utiliser la directive ExpiresDefault pour définir une date d’expiration pour tous les éléments mis en cache, ou vous pouvez définir la date d’expiration pour des types de fichiers spécifiques en utilisant ExpiresByType.

Pour plus d’informations, veuillez consulter la `documentation de mod_expires Apache2`_.

Surrogate-key¶

Vous pouvez également gérer des groupes d’objets dans le Cache en utilisant l’en-tête <tt>Surrogate-Key</tt>. Pour inscrire un objet (par exemple, une page web ou une image), il vous suffit d’inclure l’en-tête dans votre réponse avec une valeur qui correpond au groupe souhaité. Ensuite, vous aurez la possibilité de purger le cache de ce groupe en ajoutant son l’en-tête à la commande PURGE.

Par exemple, pour ajouter un objet à groupe avec PHP :

header("Surrogate-Key: foo");

Ou avec Node.js :

function (request, response) {
    response.setHeader('Surrogate-Key', 'foo');
}

Et puis pour purger tous les objets de ce groupe :

curl -X PURGE -H 'Surrogate-Key: foo' http://www.example.com/

Vous pouvez également associer un objet à plusieurs groupes et purger plusieurs groupes en même temps.

Pour cela, entrez les noms des groupes séparés par un espace : Surrogate-Key: foo bar.

Cookies¶

En règle général, les requêtes contenant des cookies ne seront pas servies depuis le cache. De même, les réponses qui écrirent des cookies avec l’en-tête set-cookie: ne seront pas cachées par notre plateforme.

Pour servir des objets depuis le cache en prenant en compte les cookies, vous pouvez utiliser un préfixe spécial dans leur nom : STYXKEY.

Quand notre plateforme reçoit une requête contenant des cookies ainsi nommés, elle servira l’objet caché s’il existe ou n’a pas expiré, ou cachera la réponse du serveur si celle-ci ne contient pas l’en-tête set-cookie.

Voici un exemple d’utilisation d’un cookie avec une clé destinée à garder le langage de l’utilisateur contenant le préfixe STYXKEY :

Un navigateur appelle la racine de votre site internet (GET /)
Votre site ou application répond avec l’entête set-cookie: STYXKEY-lang=EN -> la réponse ne sera pas cachée, puisque set-cookie est utilisé
Le navigateur garde le cookie et rappelle votre site internet (GET / à nouveau)
Votre site ou application détecte la présence du cookie STYXKEY-lang, donc la valeur est EN, et répond avec le contenu en langue anglaise et sans l’en-tête set-cookie: -> la réponse sera cachée par notre plateforme
Le navigateur rappelle votre site internet (GET / une nouvelle fois)
Notre plateforme détecte le cookie STYXKEY-lang=EN et sert l’objet caché précédemment

Notez que le préfixe doit respecter le format classique des cookies.

Pour garantir que notre plateforme prend en compte votre cookie, il est recommandé d’utiliser STYXKEY suivi de -, _ ou ., puis le nom de votre clé spécifique. Par exemple, ces cookies seront pris en compte :

STYXKEY_language=fr
STYXKEY-language=en
STYXKEY.language=de

Alors que ces cookies ne le seront pas :

language-STYXKEY=en            # Le nom du cookie doit commencer par STYXKEY
STYX-KEY-language=en           # STYXKEY doit être un seul mot
styxkey_is_case_sensitive=true # STYXKEY doit être écrit en majuscules
STYXKEY=present                # STYXKEY doit être un préfixe et non un nom de cookie

Cookies ignorés¶

De nombreux outils de suivi ajoutent des cookies pour suivre les utilisateurs et les sessions. Afin de continuer à bénéficier de notre moteur de cache, ces cookies doivent être ignorés. Nous ignorons actuellement de nombreux cookies provenant des fournisseurs de solutions de suivi les plus populaires. Ces cookies ignorés sont :

Fournisseur	Nom du Cookie
AddThis	`_atshc`
	`__atuvc`
	`__atuvs`
	`__atssc`
Cloudflare	`__cfduid`
GetClicky	`_jsuid`
Google Analytics	`_ga`
	`_gat`
	`_gid`
	`__utm[a-z]` ([a-z] signifie n’importe quelle lettre minuscule)
	`_ga_*`
	`_gac_gb_*`
	`__gads`
Hubspot	`hsfirstvisit`
	`_hstc`
	`_hssrc`
	`_hssc`
Kissmetrics	`kvcd`
	`km_ai`
	`km_lv`
	`km_uq`
	`km_vs`
piwik	`piwik_ignore`
	`_pk_ref*`
	`_pk_cvar*`
	`_pk_id*`
	`_pk_ses*`
Quantcast	`__qca`
	`__qcb`
ShareThis	`__unam`
	`__switchTo5x`
Zopim	`__zlcmid`

(un ``*`` à la fin du nom du cookie signifie « tout nom de cookie commençant par »)

Si vous pensez que des cookies supplémentaires devraient être ignorés (parce que le service n’est pas listé ou qu’il s’agisse d’un nouveau cookie d’un service répertorié), merci de rédiger un ticket à notre équipe support.

GeoIP¶

Il est possible d’utiliser la localisation GeoIP sur les Hébergements Web Gandi, en récupérant la valeur du tag X-Country-Code de l’en-tête HTTP.

La valeur renvoyée sera sous la forme FR, EN, US, GB, etc., tel que défini par la norme ISO 3166.

Vous pouvez trouver la liste complète des codes pays sur le site officiel https://www.iso.org/obp/ui/fr/#search

Le code pays est retourné en fonction de l’adresse IP du visiteur, les adresses IPv4 et IPv6 sont supportées.

Cette fonctionnalité est utile par exemple dans le cas d’un site en plusieurs langues, pour choisir la langue par défaut à afficher à votre visiteur en fonction de son pays.

En-têtes¶

Vous pouvez récupérer certaines informations sur la connexion des clients via des en-têtes HTTP, comme si vous utilisiez un serveur web classique. Les en-têtes HTTP utilisés par notre service sont les suivants :

L’adresse IP du client : “”X-Real-IP””
Données GeoIP : “”X-Country-Code”” (voir section précédente)
Utilisation de HTTPS : “”X-Forwarded-Port””, “”X-Forwarded-Proto”” et “”X-Forwarded-SSL””

Note sur l’utilisation de CloudFlare¶

Si vous utilisez CloudFlare, sachez que notre plateforme récupère les valeurs des en-têtes CF-* correspondants. Vous pouvez donc activer et désactiver CloudFlare de manière transparente.

Cependant, notez que si la connexion s’effectue par HTTPS sur CloudFlare, mais par HTTP vers Gandi, la chaîne de chiffrement est brisée. Cette pratique est tolérée, mais les en-têtes X-Forwarded-Port, X-Forwarded-Proto et X-Forwarded-SSL ne sont alors pas promus vers HTTPS.