Squid retry_on_error: Statuscodes und alternative Routen
Verwenden Sie Squid retry_on_error im dokumentierten Umfang für Statuscodes und alternative Ziele, statt es als universelle Einstellung zum Wiederholen von Anfragen zu behandeln.
Es gibt in Squid eine Option namens retry_on_error, doch der Name ist weiter gefasst als ihre sinnvolle Auslegung. Sie bedeutet nicht, dass jede fehlgeschlagene Anfrage endlos wiederholt wird, bis die Seite funktioniert.
In Versionen, die diese Direktive unterstützen, ist sie standardmäßig deaktiviert. Die dokumentierte Wiederholungsliste ist 403, 500, 501, 502, 503 und 504, und die Anfrage wird über ein anderes funktionierendes Ziel versucht. Das ist besonders in einer Hierarchie mit alternativen Weiterleitungspfaden relevant. Es ist nicht bloß ein zeitgesteuerter Wiederholungsversuch desselben Sockets an denselben Server.
Benennen Sie zuerst den Fehler
Eine Ablehnung beim Verbindungsaufbau zu einem Proxy, ein Fehler bei der Proxy-Authentifizierung, ein HTTP-Fehler des Ursprungs und eine nach Beginn der Auslieferung abgebrochene Antwort bieten nicht dieselbe Wiederholungsmöglichkeit. Erwarten Sie nicht, dass eine Einstellung alle vier gleich behandelt.
Bei einem privaten Ausgang entscheiden Sie außerdem, ob ein alternativer Pfad akzeptabel ist. Ein anderer Parent kann eine andere öffentliche Quelladresse, Authentifizierungsrichtlinie oder Netzwerkposition haben. Ein Erfolg über diese Alternative kann den Grund verletzen, aus dem der erste Parent gewählt wurde.
Anwendungsoperationen bringen ein weiteres Problem: Das Wiederholen einer Anfrage kann ihre Wirkung wiederholen. Client und Server brauchen passende Wiederholungssemantik, besonders bei Operationen, die Daten erzeugen oder ändern. Eine Proxy-Einstellung ersetzt nicht die Behandlung ungewisser Ergebnisse auf Anwendungsebene.
Lesen Sie die Direktive für Ihre genaue Version; die Referenz nennt Verfügbarkeit und Standardverhalten. Behalten Sie auch Anfragefristen und die gesamte für Nutzer sichtbare Wartezeit im Blick. Ein zusätzlicher Weiterleitungsversuch kann die verbleibende Zeit verbrauchen, ohne ein besseres Ergebnis zu liefern.
Wenn Sie sporadische Fehler untersuchen, protokollieren Sie Status, gewählten Parent oder Ziel und die Reihenfolge der Versuche. Sonst können Wiederholungen ein wiederkehrendes Routingproblem wie eine allgemein langsame Website aussehen lassen und dabei den Pfad verbergen, der tatsächlich ausgefallen ist.