Squid retry_on_error: статусни кодови и алтернативни рути

Во Squid постои опција наречена retry_on_error, но името е пошироко од нејзиното корисно толкување. Тоа не значи дека секое неуспешно барање ќе се повторува бесконечно додека страницата не проработи.

Во изданијата што ја поддржуваат оваа директива, таа е исклучена по стандард. Документираната листа за повторување е 403, 500, 501, 502, 503 и 504, а барањето се обидува преку друга работна дестинација. Ова е особено важно во хиерархија со алтернативни патеки за препраќање. Тоа не е само временски ограничено повторување на истиот сокет кон истиот сервер.

Прво именувајте го дефектот

Одбивање при поврзување со прокси, неуспех на автентикација на прокси, HTTP грешка од изворот и одговор прекинат по почетокот на испораката не нудат иста можност за повторување. Не очекувајте едно поставување да ги третира сите четири исто.

За приватен излез, одлучете и дали алтернативната патека е прифатлива. Друг родител може да има друга јавна изворна адреса, политика за автентикација или мрежна локација. Успехот преку таа алтернатива може да ја наруши причината поради која е избран првиот родител.

Операциите на апликацијата носат друга загриженост: повторувањето на барањето може да го повтори неговиот ефект. Клиентот и серверот бараат соодветна семантика за повторување, особено за операции што создаваат или менуваат податоци. Поставувањето на прокси не е замена за справување со неизвесни исходи на ниво на апликација.

Прочитајте ја директивата за вашето точно издание; референцата наведува достапност и стандардно однесување. Имајте ги на ум и роковите на барањето и вкупното чекање видливо за корисникот. Дополнителен обид за препраќање може да го потроши преостанатото време без подобар резултат.

Кога истражувате повремени дефекти, запишете го статусот, избраниот родител или дестинација и редоследот на обидите. Инаку повторувањата можат да направат повторлив проблем со рутирање да изгледа како генерално бавна веб-страница, криејќи ја патеката што всушност не успеа.