アップロードを分割して読むことにchunked HTTPは不要

いいえ。クライアントは大きなファイルを小さなバッファで読み、既知のContent-Lengthを付けて送信できます。有界な読み取りはメモリ使用量を抑え、HTTPフレーミングはリクエスト本体がどこで終わるを受信側に伝えます。

HTTPライブラリがバイト長を把握している安定したファイルは、未知の量のデータを生成するジェネレータとは異なります。どちらの入力元でも、ライブラリが対応するボディインターフェースを使ってください。長さを渡すためだけにファイル全体を文字列に組み立てる必要はありません。

HTTP/1.1では、実際に送られるフレーミングを確認してください。プロトコルの規則に従ったContent-Lengthかchunked転送コーディングです。chunkedコーディングはファイル内容の外側にサイズ標識を追加します。矛盾するフレーミング項目を併用したり、プロキシに受け入れさせるために長さを推測したりしないでください。

プロキシ経由のアップロードが失敗したら、HTTPバージョン、ボディの入力元、最初の拒否を記録します。411応答は、本体の途中で接続が閉じる場合とは別の調査を示します。代わりに認証の再試行が失敗する場合は、アップロード本体を再生できるかを確認してください。アプリケーションの読み取りバッファサイズを変えても、リクエストのフレーミングはそのままかもしれません。

その観察には経路が重要です。平文転送ではアップロードのHTTPフレーミングがプロキシに露出しますが、通常のエンドツーエンドHTTPSではトンネル内に収まります。HTTP/2は独自のフレーミングを使います。したがってSquidの歴史的な制限は特定の古い失敗を説明するものであり、現在のすべてのプロキシがストリーム送信のアップロードを拒否するという規則ではありません。