Curl-Fehler 18 - Übertragung geschlossen, ausstehende Lesedaten verbleiben

Wenn ich Daten von einer URL mit Curl abrufe, bekomme ich manchmal (in 80% der Fälle)

Fehler 18: Übertragung geschlossen mit verbleibenden ausstehenden Lesedaten

Ein Teil der zurückgegebenen Daten fehlt dann. Das Seltsame ist, dass dies niemals auftritt, wenn CURLOPT_RETURNTRANSFER auf false gesetzt ist, dh die Funktion curl_exec gibt die Daten nicht zurück, sondern zeigt den Inhalt direkt an.

Was könnte das Problem sein? Kann ich einige Optionen festlegen, um ein solches Verhalten zu vermeiden?

Ich wette, dies hängt mit einem falschen Content-LengthHeader zusammen, der vom Peer gesendet wurde. Mein Rat ist, Curl die Länge selbst einstellen zu lassen.

Die Fehlerzeichenfolge ist ganz einfach genau das, was libcurl sieht: Da es einen Chunk-Codierungsstrom empfängt, weiß es, wann in einem Chunk noch Daten zu empfangen sind. Wenn die Verbindung geschlossen wird, weiß libcurl, dass der zuletzt empfangene Block unvollständig war. Dann erhalten Sie diesen Fehlercode.

Sie können nichts tun, um diesen Fehler bei unveränderter Anforderung zu vermeiden. Sie können jedoch versuchen, ihn zu umgehen , indem Sie stattdessen eine HTTP 1.0-Anforderung ausgeben (da dann keine Chunked-Codierung erfolgt). Fakt ist jedoch, dass dies höchstwahrscheinlich ein Fehler ist auf dem Server oder in Ihrem Netzwerk / Setup irgendwie.

Ich hatte das gleiche Problem, konnte es jedoch beheben, indem ich den Header 'Expect: 100-continue' unterdrückte, den cURL normalerweise sendet (das Folgende ist PHP-Code, sollte aber ähnlich mit anderen cURL-APIs funktionieren):

curl_setopt($curl, CURLOPT_HTTPHEADER, array('Expect:'));

Übrigens sende ich Anrufe an den HTTP-Server, der im JDK 6-REST-Material enthalten ist und Probleme aller Art aufweist. In diesem Fall wird zuerst eine 100-Antwort gesendet, und bei einigen Anforderungen wird die nachfolgende 200-Antwort nicht korrekt gesendet.

Diesen Fehler auch während der Verwendung von Guzzle sehen. Der folgende Header hat es für mich behoben:

'headers' => [
    'accept-encoding' => 'gzip, deflate',
],

Ich habe die Anfrage an Postman gesendet, die mir eine vollständige Antwort und keinen Fehler gab. Dann fing ich an, die Header hinzuzufügen, die Postman an die Guzzle-Anfrage sendet, und dies war derjenige, der das Problem behoben hat.

Ich habe diesen Fehler erhalten, als mein Serverprozess während der Generierung der Antwort eine Ausnahme bekam und einfach die Verbindung schloss, ohne sich zu verabschieden. Curl erwartete noch Daten von der Verbindung und beschwerte sich (zu Recht).

Ich hatte dieses Problem mit Pycurl und habe es mit gelöst

c.setopt(pycurl.HTTP_VERSION, pycurl.CURL_HTTP_VERSION_1_0) 

wie Eric Caron sagt.

Ich habe diesen Fehler auf diese Weise behoben.

$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;

Es tritt immer noch ein Fehler auf, aber ich kann Antwortdaten in Variablen verarbeiten.

Ich habe diesen Fehler erhalten, als ich versehentlich eine Datei auf sich selbst heruntergeladen habe.
(Ich hatte einen Symlink in einem sshfs-Mount des Remote-Verzeichnisses erstellt, um ihn zum Download zur Verfügung zu stellen, vergaß, das Arbeitsverzeichnis zu wechseln, und verwendete -OJ).

Ich denke, es wird Ihnen beim Lesen nicht wirklich »helfen«, da dies bedeutet, dass Ihre Datei in den Papierkorb verschoben wurde.

Bei einem ähnlichen Problem ist mein Server hinter nginx. Es gibt keinen Fehler im Protokoll des Webservers (Python Flask), aber einige Fehlermeldungen im Nginx-Protokoll.

[krit] 31054 # 31054: * 269464 open () "/ var / cache / nginx / proxy_temp / 3/45/0000000453" ist beim Lesen des Upstreams fehlgeschlagen (13: Berechtigung verweigert)

Ich habe dieses Problem behoben, indem ich die Berechtigung des Verzeichnisses korrigiert habe:

/var/cache/nginx