Vart PHP cURL-svaret avkorta?

Kontroller overføringsresultatet til cURL, svarstatusen og kroppsrepresentasjonen før du samanliknar nedlasta storleik med Content-Length.

Byrja med resultatet til cURL når ei side lasta ned gjennom ein proxy ser ufullstendig ut. Eit kort svar, ei mislukka overføring og ei full blokkeringsside krev ulike forklaringar.

Med CURLOPT_RETURNTRANSFER slått på i det eksisterande konfigurerte handle:

$body = curl_exec($ch);
if ($body === false) {
    throw new RuntimeException(curl_error($ch), curl_errno($ch));
}

$status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$downloaded = curl_getinfo($ch, CURLINFO_SIZE_DOWNLOAD_T);
$declared = curl_getinfo($ch, CURLINFO_CONTENT_LENGTH_DOWNLOAD_T);

Samle desse verdiane før du slepp handle. Den strenge samanlikninga skil overføringsfeil frå vellukka kroppar som ein tom streng eller “0”. HTTP-feilstatusar er ikkje automatisk curl_exec-feil, så tolk òg statusen.

Teljaren for nedlasta data utelèt headarar. Den deklarerte verdien kjem frå Content-Length og er -1 når storleiken er ukjend. Eit svar kan med rette utelate Content-Length; ein ukjend verdi er ikkje ein diagnose på ei avkorta fil.

Automatisk innhaldskoding innfører endå ein skilnad. Content-Length skildrar oftast den komprimerte representasjonen, medan PHP-strengen kan innehalde dekomprimerte byte. Å samanlikne strlen($body) med den headaren samanliknar då ulike representasjonar.

cURL kan rapportere CURLE_PARTIAL_FILE når overføringa bryt ein forventa storleik. Ta vare på den feilen i staden for å handsame all ikkje-tom utdata som suksess. Omvendt kan ei vellukka overføring med eit lite 200-svar vere heile sida kjelda eller proxyen valde å returnere.

Til slutt kontroller det nødvendige innhaldet. HTML henta av cURL køyrer ikkje JavaScript for å fylle sida. Delar som nettlesaren viser, kan mangle i det opphavlege svaret sjølv når kvar overført byte har kome fram.

Relaterte artiklar