Status en útgongskoades fan in proxy-monitor ynterpretearje
Rapportearje kommandoútfiering, HTTP-útkomst en sertifikaatfalidaasje apart yn in websidekontrôle fia in proxy.
In wrapper kin in nul-útgongskoades fan de downloader net omsette yn in waarnommen „HTTP 200 OK“. Skriuw op wat elke laach feitlik rapportearre:
| Fjild | Fraach dy't beändere wurdt |
|---|---|
| Útgong fan ark of plugin | Waar de kontrôle útfierd, en hokker flaterklasse rapportearre dy? |
| Proxy-ûnderhanneling | Waar de trochstjoering of de frege tunnel talitten? |
| Oarsprongsstatus en ferwachte ynhâld | Joech de applikaasje it bedoelde resultaat werom? |
| TLS-falidaasje | Slagen de konfigurearre identiteitskontrôles? |
curl kin normaalwei nul weromjaan nei in HTTP-flater-antwurd. Syn fail-opsjes feroarje it útgongsgedrach, mar in flaterútgong identifisearret de status noch altyd net unyk. Ek de útgongswaarden fan Wget binne kategoryen: in autentikaasjeflater is gjin eigen wearde foar HTTP 401, en in tsjinnerflaterkategory identifisearret net elk antwurd deryn. In kontrôle dy't 401 ferwachtet, moat dat antwurd waarnimme.
Hâld it proxy-einpunt en de websidenamme apart. De TCP-pear fan in HTTP-proxykontrôle is de proxy; CONNECT neamt it bestimming, waans TLS-sesje dêrnei yn 'e tunnel rint. By in HTTPS-proxy is it fertrouwen yn 'e bûtenste proxy in oare sertifikaatkontrôle.
Undersykje de garânsje fan 'e plugin foardat jo in SSL-flag as ferifikaasje beskôgje. Monitoring Plugins ferklearret check_http ferâldere ten geunste fan check_curl. De dokumintaasje fan check_http warskôget dat allinnich SSL kieze de hostnamme noch it fertrouwen yn 'e útjouwer ferifiearret; de dokumintearre verify-peer-opsje fan check_curl befettet dy ferifikaasje.
Brûk ek de bedoelde autentisearre rûte. In poartprobe kin grien bliuwe wylst it operasjonele akkount 407 krijt. Leverje it geheim fia it passende meganisme fan 'e útrôl en rapportearje de stadium dy't feitlik mislearre: in wegere tunnel freget in oare reparaasje as in ûnferwachte websidestatus.