Squid retry_on_error: statusne kode in alternativne poti

V Squidu obstaja možnost z imenom retry_on_error, vendar je ime širše od njene koristne razlage. Ne pomeni, da se bo vsak neuspešen zahtevek ponavljal neskončno, dokler stran ne bo delovala.

V izdajah, ki podpirajo to direktivo, je privzeto izklopljena. Dokumentirani seznam ponovitev je 403, 500, 501, 502, 503 in 504, zahtevek pa se poskusi prek drugega delujočega cilja. To je še posebej pomembno v hierarhiji z alternativnimi potmi posredovanja. To ni le časovno omejeno ponavljanje istega vtičnika na isti strežnik.

Najprej poimenujte napako

Zavrnitev pri povezovanju s posrednikom, napaka avtentikacije posrednika, napaka HTTP iz izvora in odgovor, prekinjen po začetku dostave, ne ponujajo enake možnosti ponovitve. Ne pričakujte, da bo ena nastavitev vse štiri obravnavala enako.

Za zasebni izhod se odločite tudi, ali je alternativna pot sprejemljiva. Drugi nadrejeni strežnik ima lahko drug javni naslov vira, politiko avtentikacije ali omrežno lokacijo. Uspeh prek te alternative lahko krši razlog, zakaj je bil prvi nadrejeni strežnik izbran.

Operacije aplikacije prinašajo še eno skrb: ponovitev zahtevka lahko ponovi njegov učinek. Odjemalec in strežnik potrebujeta ustrezno semantiko ponavljanja, zlasti za operacije, ki ustvarjajo ali spreminjajo podatke. Nastavitev posrednika ne nadomešča obravnave negotovih izidov na ravni aplikacije.

Preberite direktivo za svojo natančno izdajo; referenca navaja razpoložljivost in privzeto vedenje. Upoštevajte tudi roke zahtevkov in skupno čakanje, ki ga vidi uporabnik. Dodaten poskus posredovanja lahko porabi preostali čas, ne da bi dal boljši rezultat.

Pri preiskovanju občasnih napak zabeležite status, izbranega nadrejenega strežnika ali cilj in zaporedje poskusov. Sicer lahko ponovitve povzročijo, da je ponavljajoča se težava z usmerjanjem videti kot na splošno počasno spletno mesto, medtem ko skrivajo pot, ki je dejansko spodletela.