Réponses 403 de Squid : refus frais ou erreur mise en cache ?
Distinguez un refus d'accès frais d'une réponse négative mise en cache avant de modifier la politique de durée de vie du cache de Squid.
Voir deux fois la même page 403 ne prouve pas un hit de cache. Rapprochez l'enregistrement d'accès de la transaction et les en-têtes de réponse de deux questions : qui a produit le refus, et une réponse stockée a-t-elle été réutilisée ?
- Une requête refusée localement exige la correction de sa décision de règle d'accès ou d'identité.
- Un refus frais de l'origine signifie que l'origine rejette toujours la requête.
- Une réponse d'origine réutilisée exige l'examen de sa politique de fraîcheur et de la configuration de cache applicable.
La mise en cache HTTP inclut certaines réponses négatives selon ses conditions, mais 403 ne reçoit pas de fraîcheur heuristique par défaut. Un refus qui serait normalement cachable peut porter une durée de vie explicite de cache partagé. Modifier l'autorisation à l'origine n'efface pas une réponse encore jugée fraîche ; utilisez une politique de réponse adaptée pour les décisions qui ne doivent pas être stockées.
negative_ttl de Squid est un repli distinct pour certaines requêtes en échec dont l'expiration est inconnue. Sa valeur par défaut documentée est zéro dans les versions couvertes par la référence actuelle des directives. Cela n'interdit pas les réponses d'erreur rendues fraîches par des instructions HTTP explicites.
La référence exige aussi une compilation autorisant les violations HTTP et exclut Squid 8. Ne transférez pas une suggestion de durée de vie pour Squid 2.7 vers une autre version sans vérifier la prise en charge. Supprimer un objet peut lever un symptôme immédiat ; la politique qui le rend réutilisable détermine la requête suivante.