Squid retry_on_error: statuskodar og alternative ruter

Det finst eit Squid-alternativ som heiter retry_on_error, men namnet er breiare enn den nyttige tolkinga. Det tyder ikkje at kvar mislukka førespurnad vert gjenteken i det uendelege til sida fungerer.

I versjonar som støttar dette direktivet, er det av som standard. Den dokumenterte gjentakingslista er 403, 500, 501, 502, 503 og 504, og førespurnaden vert freista via ein annan fungerande destinasjon. Dette er særleg relevant i ein hierarki med alternative videresendingsvegar. Det er ikkje berre eit tidsavgrensa nytt forsøk av same socket til same tenar.

Namngi feilen først

Ei avvising ved tilkoping til ein proxy, ein proxy-autentiseringsfeil, ein HTTP-feil frå opphavet og eit svar som vart brote etter at leveringa starta, gjev ikkje same gjentakingshøve. Ikkje vent at éi innstilling handsamar alle fire likt.

For ein privat utgang må du òg avgjere om ein alternativ veg er akseptabel. Ein annan forelder kan ha ein annan offentleg kjeldeadresse, autentiseringspolicy eller nettverksplassering. Suksess gjennom det alternativet kan bryte grunnen til at den første forelderen vart vald.

Applikasjonsoperasjonar bringar ei anna bekymring: gjentaking av ein førespurnad kan gjenta effekten. Klienten og tenaren treng passande gjentakingssemantikk, særleg for operasjonar som opprettar eller endrar data. Ei proxy-innstilling er ikkje ei erstatning for handsaming av usikre resultat på applikasjonsnivå.

Les direktivet for din nøyaktige versjon; referansen viser tilgjenge og standardåtferd. Ha òg førespurnadsfristar og den totale brukarsynlege ventetida i tankane. Eit ekstra videresendingsforsøk kan bruke opp den gjenverande tida utan å gje eit betre resultat.

Når du undersøkjer periodiske feil, registrer status, vald forelder eller destinasjon og forsøksrekkjefølgje. Elles kan gjentakingar få eit tilbakevendande ruteproblem til å sjå ut som ein generelt treg nettstad, medan dei skjuler vegen som faktisk mislukkast.