Kial ŝela proksea kontrolo restas malsukcesa post sukceso de curl

Evitu konservi malnovan curl-malsukceson en ŝela variablo post kiam postaj proksaj kontroloj sukcesas.

La prokso malsukcesas unufoje. Postaj petoj sukcesas, tamen la gardanto daŭre anoncas plian malsukceson. Kontrolu, ĉu la skripto memoris la elirstaton de hieraŭ.

Ĉi tiu ŝablono ĝisdatigas la variablon nur kiam curl malsukcesas:

status=0
# Repeated inside a loop:
curl ... || status=$?

Post la unua ne-nula rezulto, sukcesa ripeto lasas status netuŝita. Ĝi ne iĝas nulo nur ĉar curl sukcesis.

Anstataŭe branĉu laŭ la nuna komando:

if curl --proxy socks5h://127.0.0.1:1080 --noproxy '' \
    --fail --silent --show-error --connect-timeout 3 --max-time 10 \
    https://health.example/ >/dev/null; then
    echo "check succeeded"
else
    echo "check failed"
fi

La adreso kaj daŭroj estas ilustraj. Ĉi tio forigas la malnoviĝintan variablon; ĝi ne decidas, kiu rehaviga ago taŭgas.

Tenu la observadon mallarĝa. La peto dependas de la prokso, la plua vojo, la celo, TLS-kontrolo kaj la HTTP-rezulto. Ĉeso ĉe la celo povas malsukcesigi ĝin dum la SOCKS-servo estas sana. Neatendita HTTP 200-paĝo ankaŭ povas trapasi nurstatusan kontrolon sen liveri la atendatan enhavon.

Elektu kontrolitan respondan kontrakton kaj konservu la malsukcesan stadion. Restartigi la prokson ĉe ĉiu ne-nula curl-rezulto povas ĝeni sanajn sesiojn, dum la vera cela problemo restas netuŝita.

Rilataj artikoloj