El proxy entrega datos. Su función de escritura devuelve el valor incorrecto. Entonces libcurl aborta y el código circundante informa de otro «fallo de descarga a través del proxy».

La función debe informar de cuántos bytes recibidos ha gestionado realmente. Devolver un recuento distinto indica fallo. Para un destino de escritura deliberadamente bloqueante, un fragmento puede ser así:

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

Esto supone que la aplicación existente posee el handle y el destino de escritura. Una escritura fallida o corta aborta en lugar de afirmar en silencio que se guardó todo el fragmento. Un destino no bloqueante necesita un diseño adecuado de almacenamiento en búfer y pausa/reanudación; el fragmento pequeño no lo proporciona.

Cuente bytes, no caracteres mostrados. Los datos pueden ser binarios o parte de una secuencia de texto multibyte. Una llamada no es necesariamente una línea, un documento JSON ni un mensaje del servicio.

El análisis incremental necesita su propio estado entre llamadas. A la inversa, acumular cada fragmento hasta completarlo puede ser correcto para una respuesta pequeña y acotada, pero no es una política de memoria para un flujo grande o interminable.

Conserve el resultado de la transferencia y las pruebas del fallo de la función. Un error local de disco o un aborto del analizador puede ocurrir después de establecer una ruta de proxy válida. Si pretende detenerse tras un prefijo, marque esa detención deliberada por separado. Sustituir la dirección del proxy no puede reparar un destino que dejó de aceptar datos.

Artículos relacionados