Squid retry_on_error: statuskoder og alternative ruter

Der findes en Squid-indstilling kaldet retry_on_error, men navnet er bredere end dens nyttige fortolkning. Det betyder ikke, at hver mislykket forespørgsel gentages i det uendelige, indtil siden virker.

I versioner, der understøtter dette direktiv, er det slået fra som standard. Den dokumenterede gentagelsesliste er 403, 500, 501, 502, 503 og 504, og den forsøger forespørgslen gennem en anden fungerende destination. Det er især relevant i et hierarki med alternative videresendelsesveje. Det er ikke blot et tidsindstillet gentagelsesforsøg af samme socket til samme server.

Navngiv fejlen først

Et afslag under forbindelse til en proxy, en proxy-godkendelsesfejl, en HTTP-fejl fra oprindelsen og et svar, der blev afskåret efter leveringens start, giver ikke samme gentagelsesmulighed. Forvent ikke, at én indstilling behandler alle fire ens.

For en privat udgang skal du også beslutte, om en alternativ vej er acceptabel. En anden parent kan have en anden offentlig kildeadresse, godkendelsespolitik eller netværksplacering. Succes gennem det alternativ kan krænke grunden til, at den første parent blev valgt.

Applikationsoperationer bringer endnu en bekymring: gentagelse af en forespørgsel kan gentage dens effekt. Klienten og serveren har brug for passende gentagelsessemantik, især for operationer, der opretter eller ændrer data. En proxy-indstilling er ikke en erstatning for håndtering af usikre resultater på applikationsniveau.

Læs direktivet for din præcise version; referencen angiver tilgængelighed og standardadfærd. Hold også forespørgselsfrister og den samlede brugersynlige ventetid for øje. Et ekstra videresendelsesforsøg kan bruge den resterende tid uden at give et bedre resultat.

Når du undersøger periodiske fejl, skal du registrere status, valgt parent eller destination og forsøgsrækkefølge. Ellers kan gentagelser få et tilbagevendende routingproblem til at ligne et generelt langsomt websted, mens de skjuler den vej, der faktisk fejlede.