Når ein curl-test skriv 000 som HTTP-status, har curl ikkje fått nokon endeleg HTTP-svarkode å rapportere. Nettstaden sende ikkje ein faktisk HTTP-status kalla 000.

Ta òg vare på feilen

Dette dømet for eit POSIX-skal skriv ut det endelege HTTP-feltet, CONNECT-feltet og avslutningskoden til curl-prosessen:

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"

Byt ut endepunktet i dømet med HTTP-proxyen din eller ein kandidat frå lista over HTTP-proxyar. La show-error vere aktivert: feilmeldinga er ofte den nyttigaste delen. CONNECT-feltet er relevant når ein tunnel vert brukt; det er ikkje ein andre endeleg status frå nettstaden.

Les verdiane samla

  • Ei mislukka tilkopling til proxyen kan la HTTP-feltet stå på 000.
  • Eit tidsavbrot før eit svar er motteke kan gje same resultat.
  • Eit vellukka CONNECT-svar etterfølgt av ein TLS-feil kan vise connect=200 og http=000.
  • Eit fullstendig svar frå nettstaden, som 403, er noko anna: då finst det eit faktisk HTTP-svar å undersøkje.

Den nøyaktige avslutningskoden og meldinga snevrar inn årsaka. Undersøk om feilen oppstod då proxyen skulle finnast, ved tilkopling til porten, under tunnelforhandlinga eller ved verifisering av målet.

Ikkje reduser alle resultat til berre ein statussjekk

Eit skript som berre lagrar http_code, kastar bort transportfeilen. Lagre òg prosessresultatet og ei feilmelding der sensitive opplysningar er fjerna. Omvendt kan curl fullføre ei overføring utan feil sjølv om nettstaden returnerer ein feilstatus, med mindre du brukar eit passande fail-alternativ. HTTP-svaret og køyreresultatet til klienten svarar på ulike spørsmål.

Ikkje prøv å rette 000 ved å slå av TLS-verifisering eller leggje til ein tilfeldig header. Finn først ut kva operasjon som aldri nådde fram til eit endeleg svar.

Relaterte artiklar