curlを使用してURLからデータを取得すると、時々(ケースの80%で)
エラー18:未処理の読み取りデータが残っている状態で転送が終了しました
返されたデータの一部が欠落しています。奇妙なことに、CURLOPT_RETURNTRANSFERがfalseに設定されている場合、これは発生しません。つまり、curl_exec関数はデータを返さず、コンテンツを直接表示します。
何が問題なのでしょうか?そのような振る舞いを避けるためにいくつかのオプションを設定できますか?
これは間違ったContent-Length
ピアによって送信されたヘッダー。私のアドバイスは、curlに自動的に長さを設定させることです。
エラー文字列は、libcurlが見ているものとまったく同じです。チャンクエンコーディングストリームを受信しているため、受信するチャンクにデータが残っていることを認識しています。接続が閉じられると、libcurlは最後に受信したチャンクが不完全であることを認識します。次に、このエラーコードを取得します。
変更されていないリクエストでこのエラーを回避する方法はありませんが、can代わりにHTTP 1.0リクエストを発行して回避することを試みます(その場合、チャンクエンコーディングは行われないため)これはおそらく、サーバーまたはネットワーク/セットアップの欠陥である可能性が高いと思われます。
私は同じ問題を抱えていましたが、cURLが通常送信する「Expect:100-continue」ヘッダーを抑制することで修正することができました(以下はPHPコードですが、他のcURL APIでも同様に動作するはずです):
curl_setopt($curl, CURLOPT_HTTPHEADER, array('Expect:'));
ところで、JDK 6 REST stuffに含まれているHTTPサーバーに呼び出しを送信していますが、これにはあらゆる種類の問題があります。この場合、最初に100応答を送信します。その後、一部のリクエストでは後続の200レスポンスが正しく送信されません。
応答の生成中にサーバープロセスで例外が発生し、さよならを言わずに接続を閉じたときにこのエラーが発生しました。 curlはまだ接続からのデータを予期しており、(当然のことながら)文句を言いました。
Guzzleの使用中にもこのエラーが表示されます。次のヘッダーで修正されました。
'headers' => [
'accept-encoding' => 'gzip, deflate',
],
Postmanでリクエストを発行しましたが、完全な応答が返され、エラーはありませんでした。次に、PostmanがGuzzleリクエストに送信するヘッダーの追加を開始しましたが、これが修正されました。
私はpycurlでこの問題を抱えていましたが、それを使用して解決しました
c.setopt(pycurl.HTTP_VERSION, pycurl.CURL_HTTP_VERSION_1_0)
Eric Caron のような。
誤って自分自身にファイルをダウンロードしていたときに、このエラーが発生しました。
(リモートディレクトリのsshfsマウントにシンボリックリンクを作成してダウンロードできるようにし、作業ディレクトリを切り替えるのを忘れて、-OJ
)。
ファイルをゴミ箱に入れたということなので、これを読んでも本当に助けにはならないでしょう。
この方法でこのエラーを解決しました。
$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;
エラーは引き続き発生しますが、応答データを変数で処理できます。