Un wrapper nu poate transforma un cod de ieșire zero al descărcătorului într-un „HTTP 200 OK” observat. Notați ce a raportat efectiv fiecare strat:

CâmpÎntrebarea la care răspunde
Ieșirea instrumentului sau a pluginuluiS-a executat verificarea și ce clasă de eșec a raportat?
Negocierea cu proxy-ulA fost admisă redirecționarea sau tunelul cerut?
Starea originii și conținutul așteptatAplicația a returnat rezultatul dorit?
Validarea TLSAu reușit verificările de identitate configurate?

curl poate returna de obicei zero și după un răspuns de eroare HTTP. Opțiunile fail îi schimbă comportamentul la ieșire, dar o ieșire de eșec tot nu identifică starea în mod unic. Și valorile de ieșire ale Wget sunt categorii: un eșec de autentificare nu este o valoare dedicată pentru HTTP 401, iar o categorie de eroare de server nu identifică fiecare răspuns din ea. O verificare care așteaptă 401 trebuie să observe acel răspuns.

Țineți separate punctul final al proxy-ului și numele site-ului. Partenerul TCP al unei verificări prin proxy HTTP este proxy-ul; CONNECT numește destinația, a cărei sesiune TLS rulează apoi în interiorul tunelului. La un proxy HTTPS, încrederea în proxy-ul exterior este încă o verificare a certificatului.

Examinați garanția pluginului înainte de a considera un flag SSL drept verificare. Monitoring Plugins retrage check_http în favoarea check_curl. Documentația check_http avertizează că alegerea doar a SSL nu verifică nici numele gazdei, nici încrederea în emitent; opțiunea verify-peer documentată a check_curl include acea verificare.

Folosiți și ruta autentificată prevăzută. O sondă de port poate rămâne verde în timp ce contul operațional primește 407. Livrați secretul prin mecanismul adecvat al implementării și raportați etapa care a eșuat efectiv: un tunel refuzat cere o reparare diferită de o stare neașteptată a site-ului.

Articole similare