PHP cURL-schrijfcallbacks moeten het aantal verwerkte bytes teruggeven

Houd u aan het byte-aantalcontract bij het consumeren van proxy-responsfragmenten en onderscheid een lokale schrijffout van een mislukte proxyverbinding.

De proxy levert gegevens. Uw schrijfcallback geeft de verkeerde waarde terug. Dan breekt libcurl af, en de omringende code meldt nog een „proxy-downloadfout”.

De callback moet melden hoeveel ontvangen bytes hij werkelijk heeft verwerkt. Een ander aantal teruggeven signaleert een fout. Voor een bewust blokkerende schrijfput kan een fragment er zo uitzien:

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;
    }
);

Dit veronderstelt dat de bestaande toepassing de handle en de schrijfput bezit. Een mislukte of korte schrijfactie breekt af in plaats van stil te beweren dat het hele fragment is opgeslagen. Een niet-blokkerende put vereist een passend buffer- en pauze/hervat-ontwerp; het kleine fragment voorziet daar niet in.

Tel bytes, niet weergegeven tekens. De gegevens kunnen binair zijn of deel uitmaken van een multibyte tekstreeks. Eén callback is niet noodzakelijk één regel, één JSON-document of één bericht van de dienst.

Incrementele parsing heeft zijn eigen toestand nodig tussen callbacks. Omgekeerd kan het verzamelen van elk fragment tot voltooiing correct zijn voor een kleine begrensde respons, maar het is geen geheugenbeleid voor een grote of eindeloze stroom.

Bewaar het resultaat van de overdracht en het bewijs van callback-fouten. Een lokale schijffout of parserafbreking kan optreden nadat een geldige proxyroute is opgezet. Als u na een prefix wilt stoppen, markeer die bewuste callback-stop apart. Het vervangen van het proxyadres kan een put die geen gegevens meer accepteert niet repareren.

Gerelateerde artikelen