lors de la récupération de données d’une URL à l’aide de curl, j’obtiens parfois (dans 80% des cas)
erreur 18: transfert fermé avec les données de lecture en attente restantes
Une partie des données renvoyées est alors manquante. Ce qui est étrange, c'est que cela ne se produit jamais lorsque CURLOPT_RETURNTRANSFER est défini sur false, la fonction curl_exec ne renvoie pas les données mais affiche directement le contenu.
Quel pourrait être le problème? Puis-je définir certaines des options pour éviter un tel comportement?
Merci beaucoup pour vos suggestions!
Je parie que cela est lié à un en-tête Content-Length incorrect envoyé par l'homologue. Mon conseil est de laisser curl définir lui-même la longueur.
La chaîne d'erreur est tout simplement ce que voit exactement libcurl: puisqu'il reçoit un flux de codage fragmenté, il sait quand il reste des données dans un bloc à recevoir. Lorsque la connexion est fermée, libcurl sait que le dernier bloc reçu était incomplet. Ensuite, vous obtenez ce code d'erreur.
Vous ne pouvez rien faire pour éviter cette erreur si la requête n'est pas modifiée, mais vous pouvez essayer de la contourner en envoyant une requête HTTP 1.0 (car l'encodage en bloc ne se produira pas alors), mais le fait est qu'il s'agit très probablement une faille dans le serveur ou dans votre réseau/configuration en quelque sorte.
J'ai eu le même problème, mais j'ai réussi à le résoudre en supprimant l'en-tête 'Expect: 100-continue' que cURL envoie habituellement (le code suivant est PHP, mais devrait fonctionner de la même manière avec d'autres API cURL):
curl_setopt($curl, CURLOPT_HTTPHEADER, array('Expect:'));
En passant, j’envoie des appels au serveur HTTP inclus dans le fichier JDK 6 REST, qui pose toutes sortes de problèmes. Dans ce cas, il envoie d'abord une réponse 100, puis avec certaines demandes n'envoie pas correctement la réponse 200 suivante.
J'ai eu cette erreur lorsque mon processus serveur a eu une exception à mi-chemin lors de la génération de la réponse et a simplement fermé la connexion sans dire au revoir. curl attend toujours les données de la connexion et se plaint (à juste titre).
J'ai eu ce problème avec pycurl et je l'ai résolu en utilisant
c.setopt(pycurl.HTTP_VERSION, pycurl.CURL_HTTP_VERSION_1_0)
comme Eric Caron dit.
J'ai eu cette erreur quand je téléchargeais accidentellement un fichier sur lui-même.
(J'avais créé un lien symbolique dans un montage sshfs du répertoire distant pour le rendre disponible au téléchargement, oublié de changer de répertoire de travail et utilisé -OJ
).
Je suppose que cela ne vous aidera pas vraiment quand vous lirez ceci, car cela signifie que votre fichier a été mis à la corbeille.
Voir cette erreur lors de l'utilisation de Guzzle également. L'en-tête suivant l'a corrigé pour moi:
'headers' => [
'accept-encoding' => 'gzip, deflate',
],
J'ai envoyé la demande à Postman qui m'a donné une réponse complète et aucune erreur. Ensuite, j'ai commencé à ajouter les en-têtes que Postman envoie à la requête Guzzle et c'est celle-ci qui l'a corrigée.
J'ai résolu cette erreur de cette façon.
$ch = curl_init ();
curl_setopt ( $ch, CURLOPT_URL, 'http://www.someurl/' );
curl_setopt ( $ch, CURLOPT_TIMEOUT, 30);
ob_start();
$response = curl_exec ( $ch );
$data = ob_get_clean();
if(curl_getinfo($ch, CURLINFO_HTTP_CODE) == 200 ) success;
Une erreur persiste, mais je peux gérer les données de réponse dans une variable.