Squid retry_on_error: кодови за състояние и алтернативни маршрути

В Squid има опция retry_on_error, но името ѝ е по-широко от полезното ѝ тълкуване. Тя не означава, че всяка неуспешна заявка ще се повтаря безкрайно, докато страницата проработи.

При изданията, които поддържат тази директива, тя е изключена по подразбиране. Документираният списък за повторение е 403, 500, 501, 502, 503 и 504 и заявката се опитва през друга работеща дестинация. Това е особено важно в йерархия с алтернативни пътища за препращане. Това не е просто повторение по таймер на същия сокет към същия сървър.

Първо назовете отказа

Отказ при свързване с прокси, неуспешна автентикация на прокси, HTTP грешка от източника и отговор, прекъснат след началото на доставянето, не дават еднаква възможност за повторение. Не очаквайте една настройка да третира и четирите еднакво.

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

Операциите на приложението добавят още едно съображение: повторението на заявка може да повтори ефекта ѝ. Клиентът и сървърът се нуждаят от подходяща семантика на повторение, особено за операции, които създават или променят данни. Настройката на прокси не замества обработката на несигурни резултати на ниво приложение.

Прочетете директивата за точното си издание; справочникът изброява наличността и поведението по подразбиране. Дръжте под внимание и сроковете на заявката и общото видимо за потребителя изчакване. Допълнителен опит за препращане може да изразходва оставащото време, без да даде по-добър резултат.

Когато изследвате периодични откази, записвайте състоянието, избрания родител или дестинация и последователността на опитите. Иначе повторенията могат да представят повтарящ се проблем с маршрутизирането като общо бавен сайт, като крият пътя, който всъщност се е провалил.