Squid retry_on_error: statuskodes en alternatiewe roetes

Daar is 'n Squid-opsie genaamd retry_on_error, maar die naam is wyer as die nuttige interpretasie daarvan. Dit beteken nie dat elke mislukte versoek onbepaald herhaal word totdat die bladsy werk nie.

Vir weergawes wat hierdie richtlijn ondersteun, is dit by verstek af. Die gedokumenteerde herhalingslys is 403, 500, 501, 502, 503 en 504, en dit probeer die versoek deur 'n ander werkende bestemming. Dit is veral relevant in 'n hiërargie met alternatiewe aanstuurpaaie. Dit is nie bloot 'n tydgebonde herhaling van dieselfde socket na dieselfde bediener nie.

Noem eers die fout

Om te weier tydens die verbinding met 'n proxy, 'n proxy-verifikasiefout, 'n HTTP-fout van die oorsprong en 'n antwoord wat ná die begin van die aflewering afgesny is, bied nie dieselfde herhalingsgeleentheid nie. Moenie verwag dat een instelling al vier dieselfde behandel nie.

Vir 'n private uitgang moet jy ook besluit of 'n alternatiewe pad aanvaarbaar is. 'n Ander ouer kan 'n ander openbare bronadres, verifikasiebeleid of netwerklokasie hê. Sukses deur daardie alternatief kan die rede waarom die eerste ouer gekies is, verydel.

Toepassingsbewerkings bring nog 'n bekommernis: die herhaling van 'n versoek kan die effek daarvan herhaal. Die kliënt en bediener het gepaste herhalingsemantiek nodig, veral vir bewerkings wat data skep of verander. 'n Proxy-instelling is nie 'n plaasvervanger vir hantering op toepassingsvlak van onsekere uitkomste nie.

Lees die richtlijn vir jou presiese weergawe; die verwysing lys beskikbaarheid en verstekgedrag. Hou ook versoektermyn en die totale sigbare wagtyd in die oog. 'n Bykomende aansturpoging kan die oorblywende tyd verbruik sonder om 'n beter resultaat te lewer.

Wanneer jy ongereelde foute ondersoek, teken die status, gekose ouer of bestemming en die pogingreeks aan. Anders kan herhalings 'n herhalende roeteringsprobleem soos 'n algemeen stadige webwerf laat lyk terwyl dit die pad wat werklik misluk het, verberg.