Oui, Squid mettra en cache les réponses du ou des serveurs dorsaux en utilisant la méthode conventionnelle d'interprétation des en-têtes que le serveur dorsal envoie avec chaque réponse.
Une réponse typique pour un contenu dynamique qui ne doit pas être mis en cache ressemble à quelque chose comme ça :
Expires: Fri Jul 25 10:19:36 CEST 2014 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Techniquement, chacun de ces en-têtes est déjà suffisant pour déclarer le contenu de la réponse dynamique, mais la sagesse conventionnelle semble toujours les utiliser tous. Programmation du culte du cargo ou rétrocompatibilité ?
Cache-Control est l'en-tête qui doit vous préoccuper le plus. Il s'agit des instructions de mise en cache pour votre reverse proxy Squid, ainsi que pour tout serveur proxy intermédiaire de mise en cache, jusqu'au navigateur lui-même. Les options sont les suivantes :
-
private o public ; une réponse privée est spécifique à un utilisateur et ne doit pas être mise en cache, une réponse publique peut être mise en cache.
-
no-cache fait essentiellement ce qu'il semble être, à savoir une instruction de revalider la ressource pour chaque demande ultérieure. Même si, après validation, il est prouvé que la ressource est toujours valide, une réponse en cache peut encore être servie.
-
no-store une instruction claire indiquant que la réponse doit être traitée comme confidentielle et ne doit pas être stockée du tout, un peu plus forte que l'option no-cache ci-dessus.
-
max-age en secondes remplace l'en-tête Expires et indique quand une ressource a expiré et doit être purgée du cache.
-
s-maxage en secondes comme ci-dessus, mais pour les caches partagés comme les réseaux de diffusion de contenu.
Expires est la manière classique de définir l'instruction du cache, avec un simple horodatage ne dépassant pas un an dans le futur.
Pragma est un en-tête de la vieille école, il faut lui donner la valeur suivante no-cache sera interprété par tout navigateur récent comme Cache-Control: no-cache et je pense qu'elle n'est plus présente dans les spécifications plus récentes du protocole HTTP, bien qu'elle soit encore honorée pour des raisons de rétrocompatibilité historique.
Les en-têtes définis pour un contenu plus statique doivent indiquer à Squid (ainsi qu'aux navigateurs web de vos visiteurs) que ces réponses peuvent être mises en cache.
Cache-Control: no-transform,public,max-age=300,s-maxage=900
Content-Type: text/html; charset=UTF-8
Date: Fri Jul 25 10:19:36 CEST 2014 GMT
Expires: Sat Jul 26 10:19:36 CEST 2014 GMT
Le problème est qu'à moins que vous ne vidiez manuellement le contenu du cache de Squid, les objets seront stockés pendant la durée de leurs en-têtes de contrôle de cache. Squid n'a pas de dispositions comme celles que l'on trouve dans Varnish ou dans le logiciel utilisé par les CDN pour honorer les demandes de PURGE afin d'invalider des objets spécifiques mis en cache.
La solution de contournement consiste à faire en sorte que votre solution de gestion de contenu garantisse que les mises à jour des contenus statiques soient accompagnées de nouveaux noms de fichiers, plutôt que d'écraser les fichiers existants.
Bien sûr, votre configuration locale peut remplacer les instructions définies dans les en-têtes.
Et oui, dans le contexte de Squid, un reverse proxy et un accélérateur web sont la même chose .
