Squid retry_on_error : codes d'état et routes alternatives
Utilisez Squid retry_on_error dans son périmètre documenté d'états et de destinations alternatives, plutôt que de le traiter comme un réglage universel de réessai des requêtes.
Il existe dans Squid une option nommée retry_on_error, mais son nom est plus large que son interprétation utile. Elle ne signifie pas que chaque requête en échec sera répétée indéfiniment jusqu'à ce que la page fonctionne.
Dans les versions qui prennent en charge cette directive, elle est désactivée par défaut. La liste de réessai documentée est 403, 500, 501, 502, 503 et 504, et la requête est tentée via une autre destination qui fonctionne. Cela est particulièrement pertinent dans une hiérarchie avec des chemins de transfert alternatifs. Ce n'est pas simplement un réessai temporisé du même socket vers le même serveur.
Nommez d'abord la défaillance
Un refus lors de la connexion à un proxy, un échec d'authentification du proxy, une erreur HTTP de l'origine et une réponse coupée après le début de la livraison n'offrent pas la même possibilité de réessai. N'attendez pas qu'un seul réglage traite les quatre de la même manière.
Pour une sortie privée, décidez aussi si un chemin alternatif est acceptable. Un autre parent peut avoir une autre adresse publique de source, une autre politique d'authentification ou un autre emplacement réseau. Un succès via cette alternative peut violer la raison pour laquelle le premier parent a été choisi.
Les opérations applicatives apportent une autre préoccupation : répéter une requête peut répéter son effet. Le client et le serveur ont besoin d'une sémantique de réessai adaptée, en particulier pour les opérations qui créent ou modifient des données. Un réglage de proxy ne remplace pas la gestion au niveau applicatif des résultats incertains.
Lisez la directive pour votre version exacte ; la référence indique la disponibilité et le comportement par défaut. Gardez aussi à l'esprit les délais de requête et l'attente totale visible par l'utilisateur. Une tentative de transfert supplémentaire peut consommer le temps restant sans produire un meilleur résultat.
Lorsque vous examinez des défaillances intermittentes, consignez l'état, le parent ou la destination choisis et la séquence des tentatives. Sinon, les réessais peuvent faire passer un problème de routage récurrent pour un site généralement lent tout en masquant le chemin qui a réellement échoué.