Les callbacks d'écriture de PHP cURL doivent renvoyer le nombre d'octets traités

Le proxy livre les données. Votre callback d'écriture renvoie la mauvaise valeur. libcurl interrompt alors le transfert, et le code environnant signale un nouvel « échec de téléchargement via le proxy ».

Le callback doit indiquer combien d'octets reçus il a réellement traités. Renvoyer un décompte différent signale un échec. Pour un puits d'écriture volontairement bloquant, un fragment peut ressembler à ceci :

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

Cela suppose que l'application existante possède le handle et le puits d'écriture. Une écriture échouée ou partielle interrompt le transfert au lieu d'affirmer silencieusement que tout le fragment a été enregistré. Un puits non bloquant exige une conception appropriée de mise en tampon et de pause/reprise ; le petit fragment n'en fournit pas.

Comptez les octets, pas les caractères affichés. Les données peuvent être binaires ou faire partie d'une séquence de texte multioctet. Un callback ne correspond pas forcément à une ligne, à un document JSON ou à un message du service.

L'analyse incrémentale a besoin de son propre état d'un callback à l'autre. À l'inverse, accumuler chaque fragment jusqu'à la fin peut être correct pour une petite réponse bornée, mais ce n'est pas une politique de mémoire pour un flux volumineux ou sans fin.

Conservez le résultat du transfert et les preuves de l'échec du callback. Une erreur de disque locale ou un arrêt de l'analyseur peut survenir après l'établissement d'une route proxy valide. Si vous voulez vous arrêter après un préfixe, marquez cet arrêt volontaire du callback séparément. Remplacer l'adresse du proxy ne peut pas réparer un puits qui a cessé d'accepter des données.