プロキシがデータを届けます。書き込みコールバックが誤った値を返します。すると libcurl は中止し、周囲のコードはまた「プロキシ経由のダウンロード失敗」を報告します。

コールバックは、実際に処理した受信バイト数を報告しなければなりません。異なる数を返すことは失敗を意味します。意図的にブロックする書き込み先なら、断片は次のようになります:

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

これは、既存のアプリケーションがハンドルと書き込み先を所有していることを前提とします。書き込みの失敗や短い書き込みは、チャンク全体が保存されたと黙って主張するのではなく中止します。非ブロッキングの書き込み先には適切なバッファリングと一時停止/再開の設計が必要であり、この小さな断片はそれを提供しません。

表示される文字ではなくバイトを数えてください。データはバイナリであったり、マルチバイトのテキスト列の一部であったりします。1 回のコールバックが 1 行、1 つの JSON 文書、またはサービスからの 1 メッセージとは限りません。

インクリメンタルな解析にはコールバック間で独自の状態が必要です。逆に、完了までチャンクをすべて蓄積する方法は、小さく有界な応答には正しいことがありますが、大規模または終わりのないストリームに対するメモリ方針にはなりません。

転送結果とコールバック失敗の証拠を残してください。有効なプロキシ経路が確立された後に、ローカルのディスクエラーやパーサーの中止が起こることがあります。接頭辞の後で止めたい場合は、その意図的なコールバック停止を別に記録してください。プロキシのアドレスを置き換えても、データの受け入れを止めた書き込み先は修復できません。

関連記事