PHP cURL:s skrivcallbacks måste returnera antalet hanterade byte
Följ byte-antalskontraktet när du konsumerar svarsbitar från proxyn och skilj ett lokalt skrivfel från en misslyckad proxyanslutning.
Proxyn levererar data. Din skrivcallback returnerar fel värde. Då avbryter libcurl, och koden runt omkring rapporterar ännu ett „proxy-nedladdningsfel”.
Callbacken måste rapportera hur många mottagna byte den faktiskt hanterade. Att returnera ett annat antal signalerar fel. För en avsiktligt blockerande skrivmottagare kan en fragment se ut så här:
curl_setopt($handle, CURLOPT_PROXY, 'http://proxy.example:8080');
curl_setopt($handle, CURLOPT_WRITEFUNCTION,
function ($handle, $chunk) use ($sink) {
$written = fwrite($sink, $chunk);
return $written === false ? 0 : $written;
}
);Detta förutsätter att den befintliga applikationen äger handtaget och skrivmottagaren. En misslyckad eller kort skrivning avbryter i stället för att tyst påstå att hela biten sparades. En icke-blockerande mottagare behöver en lämplig buffrings- och paus/återupptagningsdesign; det lilla fragmentet ger ingen sådan.
Räkna byte, inte visade tecken. Data kan vara binär eller del av en flerbytes textsekvens. En callback är inte nödvändigtvis en rad, ett JSON-dokument eller ett meddelande från tjänsten.
Inkrementell parsning behöver sitt eget tillstånd mellan anrop. Omvänt kan insamling av varje bit till slutförande vara korrekt för ett litet avgränsat svar, men det är ingen minnespolicy för en stor eller ändlös ström.
Behåll överföringsresultatet och beviset på callbackfel. Ett lokalt diskfel eller parseravbrott kan inträffa efter att en giltig proxyväg upprättats. Om du tänker stoppa efter ett prefix, markera det avsiktliga callbackstoppet separat. Att byta proxyadress kan inte reparera en mottagare som slutat ta emot data.