Squid retry_on_error: статусни кодови и алтернативне руте
Користите Squid retry_on_error у документованом обухвату статуса и алтернативних одредишта, уместо да га третирате као универзално подешавање за понављање захтева.
У Squid-у постоји опција названа retry_on_error, али назив је шири од њеног корисног тумачења. То не значи да ће сваки неуспешни захтев бити понављан без ограничења док страница не проради.
У издањима која подржавају ову директиву, она је подразумевано искључена. Документована листа понављања је 403, 500, 501, 502, 503 и 504, а захтев се покушава кроз друго радно одредиште. То је посебно важно у хијерархији са алтернативним путевима прослеђивања. То није само временски ограничено понављање истог сокета ка истом серверу.
Прво именујте квар
Одбијање при повезивању са проксијем, неуспешна аутентификација проксија, HTTP грешка извора и одговор прекинут након почетка испоруке не пружају исту могућност понављања. Не очекујте да ће једно подешавање сва четири третирати исто.
За приватни излаз такође одлучите да ли је алтернативни пут прихватљив. Други родитељ може имати другу јавну изворну адресу, политику аутентификације или мрежну локацију. Успех кроз ту алтернативу може нарушити разлог због којег је први родитељ изабран.
Операције апликације доносе још једну бригу: понављање захтева може поновити његов ефекат. Клијент и сервер требају одговарајућу семантику понављања, посебно за операције које стварају или мењају податке. Подешавање проксија није замена за руковање неизвесним исходима на нивоу апликације.
Прочитајте директиву за ваше тачно издање; референца наводи доступност и подразумевано понашање. Имајте на уму и рокове захтева и укупно кориснику видљиво чекање. Додатни покушај прослеђивања може потрошити преостало време без бољег резултата.
Када истражујете повремене кварове, запишите статус, изабраног родитеља или одредиште и редослед покушаја. Иначе понављања могу учинити да проблем рутирања који се понавља изгледа као генерално спор сајт, кријући пут који је заиста заказао.