gzip バイトをそれを説明するヘッダーとともに転送する
Requests ベースのプロキシでエンコード済みまたはデコード済みのペイロードを選び、下流のレスポンスに対応する content ヘッダーと独自のフレーミングを与えます。
Requests がすでにボディを展開している場合、Content-Encoding: gzip を付けて転送すると、次のクライアントに再度展開を要求することになります。ヘッダーをコピーする前に、プロキシがどちらのペイロード表現を送るかを決めてください。
| 送信するペイロード | content ヘッダー |
|---|---|
| 元のエンコード済みバイト | 該当するエンコーディングと正確なペイロード長を維持する |
| デコード済みバイト | デコード済みのエンコーディングを削除し、対応する長さを削除または再計算する |
エンコード済みのペイロードバイトでは、この断片は content デコードなしで urllib3 の生ストリームを読み取ります:
with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
upstream.raise_for_status()
for block in upstream.raw.stream(65536, decode_content=False):
downstream.write(block)downstream は既存のレスポンス出力です。そのステータスとヘッダーはすでに選択したポリシーに従っている必要があります。この断片は完全なプロキシサーバーを実装するものではありません。
転送フレーミングは gzip の content エンコーディングとは別です。上流の HTTP ライブラリはチャンク除去を含むフレーミングをすでに処理しているため、Transfer-Encoding を盲目的にコピーしないでください。下流のサーバーは、ペイロードが gzip でエンコードされたままでも独自のレスポンスをフレーミングします。
response.text の後に UTF-8 エンコーディングを行うことも表現を変え、任意のバイナリデータを保持できません。すべての経路で上流のレスポンスを閉じるか消費し、プロキシの契約に従って HTTP エラーを処理してください。この例では転送せずに送出します。