Squid retry_on_error: kody stanu i trasy alternatywne

W Squidzie istnieje opcja o nazwie retry_on_error, ale nazwa jest szersza niż jej użyteczna interpretacja. Nie oznacza, że każde nieudane żądanie będzie powtarzane w nieskończoność, aż strona zacznie działać.

W wersjach obsługujących tę dyrektywę jest ona domyślnie wyłączona. Udokumentowana lista ponowień to 403, 500, 501, 502, 503 i 504, a żądanie jest próbowane przez inne działające miejsce docelowe. Ma to szczególne znaczenie w hierarchii z alternatywnymi ścieżkami przekazywania. To nie jest tylko ograniczone czasowo ponowienie tego samego gniazda do tego samego serwera.

Najpierw nazwij awarię

Odmowa podczas łączenia z proxy, błąd uwierzytelniania proxy, błąd HTTP od źródła i odpowiedź przerwana po rozpoczęciu dostarczania nie dają tej samej szansy na ponowienie. Nie oczekuj, że jedno ustawienie potraktuje wszystkie cztery jednakowo.

Dla prywatnego wyjścia zdecyduj też, czy alternatywna ścieżka jest akceptowalna. Inny rodzic może mieć inny publiczny adres źródłowy, politykę uwierzytelniania lub lokalizację sieciową. Sukces przez tę alternatywę może naruszyć powód wybrania pierwszego rodzica.

Operacje aplikacji wnoszą kolejne zastrzeżenie: powtórzenie żądania może powtórzyć jego efekt. Klient i serwer potrzebują odpowiedniej semantyki ponawiania, zwłaszcza w przypadku operacji tworzących lub zmieniających dane. Ustawienie proxy nie zastępuje obsługi niepewnych wyników na poziomie aplikacji.

Przeczytaj dyrektywę dla swojej dokładnej wersji; dokumentacja wymienia dostępność i domyślne zachowanie. Miej też na uwadze terminy żądań i całkowity widoczny dla użytkownika czas oczekiwania. Dodatkowa próba przekazania może zużyć pozostały czas, nie dając lepszego wyniku.

Badając sporadyczne awarie, zapisuj stan, wybranego rodzica lub miejsce docelowe oraz kolejność prób. W przeciwnym razie ponowienia mogą sprawić, że powtarzający się problem z routingiem będzie wyglądał jak ogólnie wolna witryna, ukrywając ścieżkę, która faktycznie zawiodła.