Squid retry_on_error: statusskodo kaj alternativaj vojoj
Uzu Squid retry_on_error laŭ ĝia dokumentita amplekso de statusskodo kaj alternativa celo, anstataŭ trakti ĝin kiel universalan agordon por ripeti petojn.
En Squid ekzistas opcio nomata retry_on_error, sed la nomo estas pli larĝa ol ĝia utila interpreto. Ĝi ne signifas, ke ĉiu malsukcesa peto estos senlime ripetata ĝis la paĝo funkcios.
En eldonoj subtenantaj ĉi tiun direktivon, ĝi estas malŝaltita defaŭlte. La dokumentita ripeta listo estas 403, 500, 501, 502, 503 kaj 504, kaj ĝi provas la peton tra alia funkcianta celo. Tio estas aparte grava en hierarkio kun alternativaj plusendaj vojoj. Ĝi ne estas nur tempigita ripeto de la sama ingo al la sama servilo.
Unue nomu la malsukceson
Rifuzo dum konekto al prokurilo, malsukceso de prokurila aŭtentigo, HTTP-eraro de la origino kaj respondo distranĉita post komenco de liverado ne prezentas la saman ripetan ŝancon. Ne atendu, ke unu agordo traktos ĉiujn kvar same.
Por privata eliro ankaŭ decidu, ĉu alternativa vojo estas akceptebla. Alia gepatro povas havi alian publikan fontadreson, aŭtentigan politikon aŭ retan lokon. Sukceso tra tiu alternativo povas malobservi la kialon, pro kiu la unua gepatro estis elektita.
Aplikaj operacioj alportas alian zorgo: ripeti peton povas ripeti ĝian efikon. La kliento kaj servilo bezonas taŭgan ripetan semantikon, precipe por operacioj, kiuj kreas aŭ ŝanĝas datumojn. Prokura agordo ne anstataŭas pritraktadon de necertaj rezultoj je la aplika nivelo.
Legu la direktivon por via preciza eldono; la referenco listigas haveblecon kaj defaŭltan konduton. Ankaŭ atentu petajn limdatojn kaj la tutan videblan atendon de la uzanto. Plia plusenda provo povas konsumi la restantan tempon sen doni pli bonan rezulton.
Kiam vi esploras intermitajn malsukcesojn, registru la statusskodon, la elektitan gepatron aŭ celon kaj la sinsekvon de provoj. Alie ripetoj povas igi ripetiĝantan vojigan problemon aspekti kiel ĝenerale malrapida retejo, dum ili kaŝas la vojon, kiu fakte malsukcesis.