PDF やスプレッドシートのはずのファイルが HTTP/1.1 200 OK で始まる場合、ダウンローダーはファイルではなく生のレスポンスを保存しています。この模式的なレスポンスに含まれる内容は四バイトだけです。

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

ファイル本体は DATA です。ステータス行、ヘッダー、サイズ標識、終端構造は HTTP に属します。ヘッダーの長さは一定ではないため、固定バイト数を削除するのは安全ではありません。最初の空行より後をすべてコピーしてもチャンクのフレーミングは残り、情報レスポンスが最終レスポンスの前に来ることもあります。

通常のダウンロードでは、生ソケットからファイルへのコピーを HTTP クライアントのレスポンスボディ・インターフェースに置き換えます。そのプロキシを設定し、最終ステータスを検証し、ボディを一時出力へストリームします。メッセージのフレーミングはクライアントが処理します。長さ区切り、チャンク、接続区切りのボディはそれぞれ異なる解析が必要です。

内容の符号化はさらに別の層です。クライアントの文書化された動作に基づき、デコードされたファイルのバイトが必要なのか、明示的に要求した生の内容が必要なのかを決めます。圧縮されたバイトは自動的にプロキシの破損ではありません。

アプリケーションがソケットレベルのコードを保持しなければならない場合、それらの解析規則と読み書きの処理もすべてその責任になります。読み取りが実際に返したバイト数だけを書き込み、バッファーの容量ではありません。部分書き込みも処理します。そうしなければ、古いバッファーの内容が正しく抽出されたボディさえ壊す可能性があります。

HTTPS は CONNECT レスポンスを剥がすだけでは足りません。トンネル確立後に宛先の TLS を確立し、そのうえで内側の HTTP レスポンスを解析します。プロキシのヘッダーに続く暗号化バイトはダウンロード対象のファイルではありません。

失敗した、または不完全な出力は一時的な名前のままにします。転送と ファイル検証 が成功してから公開します。空でないファイルは完全なダウンロードを証明しません。

関連記事