Kiam testo per curl montras 000 por la HTTP-stato, ĝi ne ricevis finan HTTP-respondkodon por raporti. La retejo ne sendis efektivan HTTP-staton nomatan 000.

Registru ankaŭ la eraron

Ĉi tiu ekzemplo por POSIX-ŝelo presas la finan HTTP-kampon, la CONNECT-kampon kaj la elirkodon de la curl-procezo:

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --silent --show-error --output /dev/null --write-out 'http=%{http_code} connect=%{http_connect}\n' https://example.com/
result=$?
printf 'curl_exit=%s\n' "$result"

Anstataŭigu la ekzemplan finpunkton per via HTTP-prokurilo aŭ kandidato el la listo de HTTP-prokuriloj. Lasu show-error aktiva: la erarmesaĝo ofte estas la plej utila parto. La CONNECT-kampo gravas kiam tunelo estas uzata; ĝi ne estas dua fina stato de la retejo.

Legu la valorojn kune

  • Malsukcesa konekto al la prokurilo povas lasi la HTTP-kampon je 000.
  • Tempolima eksvalidiĝo antaŭ ricevo de respondo povas doni la saman rezulton.
  • Sukcesa CONNECT-respondo sekvata de TLS-eraro povas montri connect=200 kaj http=000.
  • Kompleta respondo de la retejo, ekzemple 403, estas alia situacio: ekzistas efektiva HTTP-respondo por ekzameni.

La preciza elirkodo kaj mesaĝo malvastigas la eblajn kaŭzojn. Kontrolu ĉu la malsukceso okazis dum trovado de la prokurilo, konektado al ĝia pordo, intertraktado de la tunelo aŭ kontrolado de la celo.

Ne reduktu ĉiun rezulton al nura statokontrolo

Skripto kiu konservas nur http_code forĵetas la transportan eraron. Konservu ankaŭ la procezan rezulton kaj erarmesaĝon sen sentemaj informoj. Inverse, curl povas sukcese fini transigon dum la retejo liveras erarstaton, krom se vi uzas taŭgan fail-opcion. La HTTP-respondo kaj la rulrezulto de la kliento respondas malsamajn demandojn.

Ne provu ripari 000 malŝaltante TLS-kontrolon aŭ aldonante hazardan kaplinion. Unue determinu kiu operacio neniam atingis finan respondon.

Rilataj artikoloj