Mise en cache HTTP
Le cache HTTP stocke une réponse associée à une requête et réutilise la réponse stockée pour les requêtes ultérieures.
Il y a plusieurs avantages à la réutilisation. Tout d'abord, comme il n'est pas nécessaire de transmettre la requête au serveur d'origine, plus le client et le cache sont proches, plus la réponse est rapide. L'exemple le plus typique est lorsque le navigateur lui-même stocke un cache pour les requêtes du navigateur.
De plus, lorsqu'une réponse est réutilisable, le serveur d'origine n'a pas besoin de traiter la requête — il n'a donc pas besoin d'analyser et de router la requête, de restaurer la session en fonction du cookie, d'interroger la base de données pour obtenir des résultats ou de rendre le moteur de template. Cela réduit la charge sur le serveur.
Le bon fonctionnement du cache est crucial pour la santé du système.
Types de caches
Dans la spécification Cache HTTP (angl.), il existe deux principaux types de caches : caches privés et caches partagés.
Caches privés
Un cache privé est un cache lié à un client spécifique — typiquement un cache de navigateur. Comme la réponse stockée n'est pas partagée avec d'autres clients, un cache privé peut stocker une réponse personnalisée pour cet·te utilisateur·ice.
En revanche, si des contenus personnalisés sont stockés dans un cache autre qu'un cache privé, d'autres utilisateur·ice·s peuvent être en mesure de récupérer ces contenus — ce qui peut entraîner une fuite d'informations involontaire.
Si une réponse contient des contenus personnalisés et que vous souhaitez stocker la réponse uniquement dans le cache privé, vous devez définir une directive private.
Cache-Control: private
Les contenus personnalisés sont généralement contrôlés par des cookies, mais la présence d'un cookie n'indique pas toujours qu'il est privé, et donc un cookie seul ne rend pas la réponse privée.
Caches partagés
Le cache partagé est situé entre le client et le serveur et peut stocker des réponses pouvant être partagées entre les utilisateur·ice·s. Les caches partagés peuvent être subdivisés en caches mandataires et caches gérés.
Caches mandataires
En plus de la fonction de contrôle d'accès, certains mandataires mettent en œuvre la mise en cache pour réduire le trafic sortant du réseau. Cela n'est généralement pas géré par le·la développeur·euse du service, il doit donc être contrôlé par des en-têtes HTTP appropriés, etc. Cependant, par le passé, les implémentations de cache mandataires obsolètes — telles que les implémentations qui ne comprenaient pas correctement la norme HTTP Caching — ont souvent causé des problèmes aux développeur·euse·s.
Les en-têtes fourre-tout comme le suivant sont utilisés pour essayer de contourner les implémentations de cache mandataires « anciennes et non mises à jour » qui ne comprennent pas les directives actuelles de la spécification de cache HTTP comme no-store.
Cache-Control: no-store, no-cache, max-age=0, must-revalidate, proxy-revalidate
Cependant, ces dernières années, avec la généralisation de HTTPS et le chiffrement des communications client/serveur, les caches mandataires situés sur le chemin ne peuvent, dans de nombreux cas, que faire transiter une réponse sans pouvoir agir comme un cache. Ainsi, dans ce scénario, il n'est pas nécessaire de se préoccuper des implémentations de cache mandataires obsolètes qui ne peuvent même pas voir la réponse.
En revanche, si un mandataire passerelle TLS déchiffre toutes les communications en agissant comme une personne au milieu, en installant un certificat provenant d'une autorité de certification (CA) gérée par l'organisation sur le PC, et effectue un contrôle d'accès, etc. — il est alors possible de voir le contenu de la réponse et de le mettre en cache. Cependant, depuis que la transparence des certificats (CT) s'est généralisée ces dernières années, et que certains navigateurs n'acceptent que les certificats émis avec un SCT (certificat horodaté signé), cette méthode nécessite l'application d'une politique d'entreprise. Dans un tel environnement contrôlé, il n'est pas nécessaire de se préoccuper d'un cache mandataire « obsolète et non mis à jour ».
Caches gérés
Les caches gérés sont explicitement déployés par les développeur·euse·s de service pour décharger le serveur d'origine et fournir le contenu efficacement. Parmi les exemples, on trouve les mandataires inverses, les CDN et les service workers associés à l'API Cache.
Les caractéristiques des caches gérés varient selon le produit déployé. Dans la plupart des cas, vous pouvez contrôler le comportement du cache à l'aide de l'en-tête Cache-Control et de vos propres fichiers de configuration ou tableaux de bord.
Par exemple, la spécification de la mise en cache HTTP ne définit pas réellement de méthode pour supprimer explicitement un cache — mais avec un cache géré, la réponse stockée peut être supprimée à tout moment par des opérations sur le tableau de bord, des appels d'API, des redémarrages, etc. Cela permet d'adopter une stratégie de mise en cache plus proactive.
Il est également possible d'ignorer les protocoles de la spécification standard de la mise en cache HTTP au profit d'une manipulation explicite. Par exemple, il est possible de définir ce qui suit pour exclure un cache privé ou un cache mandataire, tout en utilisant votre propre stratégie pour ne mettre en cache que dans un cache géré.
Cache-Control: no-store
Par exemple, Varnish Cache utilise une logique VCL (Varnish Configuration Language, un type de DSL) pour gérer le stockage du cache, tandis que les service workers associés à l'API Cache permettent de créer cette logique en JavaScript.
Cela signifie que si un cache géré ignore intentionnellement une directive no-store, il n'est pas nécessaire de le considérer comme « non conforme » à la norme. Ce qu'il faut faire, c'est éviter d'utiliser des en-têtes fourre-tout, mais lire attentivement la documentation du mécanisme de cache géré que vous utilisez, et vous assurer de contrôler correctement le cache selon les moyens fournis par le mécanisme choisi.
Notez que certains CDN fournissent leurs propres en-têtes qui ne sont efficaces que pour ce CDN (par exemple, Surrogate-Control). Actuellement, des travaux sont en cours pour définir un en-tête CDN-Cache-Control (angl.) afin de standardiser ces derniers.
