Det finnes et Squid-alternativ som heter retry_on_error, men navnet er bredere enn den nyttige tolkningen. Det betyr ikke at hver mislykkede forespørsel gjentas i det uendelige til siden fungerer.

I versjoner som støtter dette direktivet, er det av som standard. Den dokumenterte gjentakelseslisten er 403, 500, 501, 502, 503 og 504, og forespørselen forsøkes via en annen fungerende destinasjon. Dette er spesielt relevant i et hierarki med alternative videresendingsveier. Det er ikke bare et tidsbestemt nytt forsøk av samme socket til samme server.

Navngi feilen først

En avvisning ved tilkobling til en proxy, en proxy-autentiseringsfeil, en HTTP-feil fra opprinnelsen og et svar som ble avbrutt etter at leveringen startet, gir ikke samme gjentakelsesmulighet. Ikke forvent at én innstilling behandler alle fire likt.

For en privat utgang må du også avgjøre om en alternativ vei er akseptabel. En annen forelder kan ha en annen offentlig kildeadresse, autentiseringspolicy eller nettverksplassering. Suksess gjennom det alternativet kan bryte grunnen til at den første forelderen ble valgt.

Applikasjonsoperasjoner bringer en annen bekymring: gjentakelse av en forespørsel kan gjenta effekten. Klienten og serveren trenger passende gjentakelsessemantikk, særlig for operasjoner som oppretter eller endrer data. En proxy-innstilling er ikke en erstatning for håndtering av usikre resultater på applikasjonsnivå.

Les direktivet for din nøyaktige versjon; referansen viser tilgjengelighet og standardadferd. Ha også forespørselsfrister og den totale brukersynlige ventetiden i tankene. Et ekstra videresendingsforsøk kan bruke opp den gjenværende tiden uten å gi et bedre resultat.

Når du undersøker periodiske feil, registrer status, valgt forelder eller destinasjon og forsøksrekkefølge. Ellers kan gjentakelser få et tilbakevendende ruteproblem til å se ut som et generelt treg nettsted, mens de skjuler veien som faktisk mislyktes.

Relaterte artikler