What Is Chunked Transfer Encoding?

スクレイプレスユニバーサルスクレイピングAPIは、リクエスト面を管理された形で通して公開ウェブコンテンツを取得し、クライアントがオリジンサーバーメッセージのフレーミングを制御する必要なくレスポンスボディを返すことができます。

定義と短い回答

チャンク転送エンコーディングは、送信者が送信開始前に完全なボディの長さを提供しない場合に、ボディを独立したサイズのチャンクのシーケンスとして送信するHTTP/1.1のメッセージフレーミング手法です。各チャンクはそのサイズを16進数で開始し、その数のオクテットのデータを続け、キャリッジリターンとラインフィードのペアで終了します。ゼロサイズのチャンクがボディの終わりを示します。このメカニズムは、1つのネットワークホップでメッセージをフレーミングします。メディアタイプを定義したり、表現を独自に圧縮したり、リソースを独立可能なファイルに分割したりすることはありません。

チャンク処理の実際的な理由はタイミングです。アプリケーションはレポートを行ごとに生成したり、他のサービスからの出力をストリーミングしたり、すべてのバイトが知られる前に動的にレンダリングされたレスポンスを送信し始めたりすることがあります。HTTP/1.1では、信頼できる境界、通常はContent-Lengthフィールドや接続のクローズが必要です。チャンクフレーミングは、その境界を提供しながら接続を持続可能にします。受信者は各サイズ行を解析し、正確に宣言されたオクテット数を消費し、サーバーがソケットを閉じるのを待たずに完了を認識できます。

チャンク転送エンコーディングはホップごとに行われます。リバースプロキシはチャンクレスポンスを受信し、それをデコードし、コンテンツをバッファリングまたは変換し、Content-Lengthまたは異なるチャンクレイアウトで転送できます。そのため、アプリケーションコードはデコードされたボディとレスポンスの完全性を気にするべきであり、単一のポイントで観察されたチャンクがエンドツーエンドで生存することを仮定すべきではありません。Content-Encodingは異なります：gzipや別のコンテンツコーディングがリクエストパス全体にわたって表現がどのようにエンコードされるかを説明しますが、Transfer-Encodingは隣接するHTTP参加者間のフレーミングを説明します。

HTTP/2とHTTP/3は、ボディフレーミングのためにHTTP/1.1 Transfer-Encodingヘッダーを使用しません。これらのプロトコルは、独自のバイナリフレーム層でデータを運びます。開発者はストリーミングデータを見ることがありますが、輸送表現はHTTP/1.1のチャンクコーディングではありません。この区別は、ゲートウェイがブラウザからHTTP/2を受け入れ、オリジンにHTTP/1.1を話すことができるため、ルートの片側でのみチャンクトラフィックを生成するため、ログやデバッグツールで重要です。

HTTP/1.1チャンクボディがフレーム化される方法

1. 転送コーディングを読みます。 受信者はTransfer-Encodingをチェックし、最終的なコーディングをフレーミングルールとして扱います。チャンクが存在する場合、Content-Lengthは同じメッセージボディを定義してはなりません。相反するフレーミングメタデータは危険です。なぜなら異なる中継者がリクエストまたはレスポンスの終了位置について意見が分かれる可能性があるからです。
2. 16進数のサイズを解析します。 各チャンクは1つ以上の16進数の数字で始まります。その値はデータオクテットをカウントし、表示可能な文字をカウントするものではありません。したがって、マルチバイトテキストはJavaScriptの文字列の長さや文字数で測定することはできません。フレーミングは転送されたバイトに基づいて動作します。
3. データと区切りを正確に消費します。 サイズ行の後、パーサーは宣言されたオクテット数を消費し、次に必要な行末を処理します。サイズの不一致、区切りの不足、またはゼロチャンクの前の接続のクローズはメッセージを不完全にします。十分にテストされたHTTPライブラリは、ボディをアプリケーションコードに公開する前にこの境界ロジックを処理します。
4. 最後のチャンクで終了します。 ゼロサイズのチャンクはチャンクシーケンスを終了します。任意のトレーラーセクションが最終的な空行の前に続くことができますが、トレーラーはストリーミング後に計算されるフィールドに対してのみ適切です。彼らは受信者がボディを読む前に必要な欠落したヘッダーを修正することはありません。

実際のシステムにおけるチャンク転送エンコーディング

チャンクエンコーディングの比較と近隣の概念

サイドバイサイドのビューは、近隣の概念が互換性があるものとして扱われるのを防ぎます。クライアントまたはサーバーの動作を変更する前に、どの契約がアクティブであるかを特定するために比較を使用します。

チャンク転送エンコーディング診断と運用設計

チャンク化されたレスポンスが切り捨てられている場合は、最初にどのホップが失敗を引き起こしたかを特定します。ブラウザの開発者ツールは通常、デコードされたボディを表示し、パケットキャプチャまたは冗長なコマンドラインクライアントはワイヤーレベルのサイズ行を明らかにします。リクエスト識別子によって、オリジン、ゲートウェイ、コンテンツ配信ネットワーク、およびクライアントログを比較します。完全なアプリケーションペイロードは、プロキシタイムアウトによって切り捨てられる可能性があり、正しいゼロチャンクは論理的に不完全なアプリケーションドキュメントを囲むことがあります。

通常のHTTPクライアントによって返されたレスポンスを手動でデチャンクしないでください。成熟したクライアントはトランスポートフレーミングを削除し、バイトストリームまたはデコードされたボディを露出します。チャンクマーカーを再度解析すると、偶然に16進数の行を含む正当なコンテンツを壊す可能性があります。手動の解析は、プロトコルテスト、ネットワーク診断、サーバー、プロキシ、そして生バイトが意図的に利用可能な専門クライアントに該当します。

セキュリティレビューは、曖昧なフレーミングをプロトコルの問題として扱うべきであり、化粧的なヘッダーの問題として扱うべきではありません。矛盾した長さの信号を持つメッセージは、隣接するシステムによって異なる解釈をされる可能性があります。信頼できる境界で着信リクエストを正規化し、誤ったフレーミングを拒否し、プロキシとオリジンの動作を整合わせ、曖昧なメッセージをアプリケーションスタック内に深く渡るのを避けてください。

チャンク転送エンコーディング実装チェックリスト

以下のチェックリストは、概念を検証可能なエンジニアリング作業に変えます。アクティブなプロトコルと製品契約に一致する項目のみを適用し、他のエンジニアが決定を再構築できるように証拠を一緒に保持します。

• ブラウザのURLから推測するのではなく、すべての関連するホップで交渉されたHTTPバージョンを確認してください。
• Transfer-EncodingとContent-Lengthを一緒に検査してください。有効なフレーミングは、受取人に矛盾した境界の間で選択を求めるべきではありません。
• システムテストの一部として生の解析がある場合、オクテットでチャンクサイズを測定し、必要な行末を検証します。
• ゲートウェイがボディをバッファリング、デコンプレッシング、または再構築するかどうかを記録します。なぜなら、そのステップは下流のツールが観察するものを変えるからです。
• リクエスト識別子を使用して、不完全なメッセージのためにクライアント、プロキシ、およびオリジンの証拠を接続します。
• 早期接続の閉鎖と不正な最終チャンクを制御された環境でテストし、失敗を明示的にします。
• 標準HTTPライブラリが、プロトコル実装が実際のタスクでない限り、アプリケーションコードにデコードされたボディを露出させるようにします。

実装後は、制御された環境で通常の動作、境界、不正な入力、欠落する状態、同時活動、および意図的なアクセス拒否をテストします。各ケースについて期待されるステータス、ボディの形状、終了条件、および状態遷移を記録します。プロダクションモニタリングは、インシデントが既知のベースラインと比較できるように、テスト中に使用されたのと同じ次元を報告する必要があります。

文書はインターフェースの両側の責任を明示する必要があります。クライアントは必須のフィールド、安定した識別子、順序ルール、制限、端末信号、およびエラーの意味が必要です。オペレーターは、内部ポリシー、ストレージまたはルーティングの決定、可視性フィールド、および安全な公開応答が必要です。曖昧な契約は、チームが間違ったレイヤーで目に見える症状を修正させることがあります。

チャンク転送エンコーディングに関する一般的な誤り

成功、欠如、許可、順序、または完了を周囲の契約なしで1つのフィールドから推測しないでください。ステータスコード、トークン、ページサイズ、およびトランスポートヘッダーは、それぞれ狭い質問に答えます。レスポンスボディ、メソッド、アイデンティティ、フィルター、プロトコルバージョン、およびサーバーの文書が残りの意味を提供します。

簡素化の名の下に診断コンテキストを削除しないでください。リクエスト識別子、ターゲット、バージョン、スコープ、または境界を省略した短いログ行は、小さな欠陥を数時間の推測作業に変えることができます。同時に、可視性は資格情報、セッションシークレット、署名付きURL、およびセンシティブなペイロードフィールドを赤外線処理する必要があります。

一時的な運用上のワークアラウンドを恒久的な契約に変えないでください。根本的な順序、許可、ルーティング、ペーシング、フレーミング、またはエラーマッピングの問題を修正し、回帰チェックを追加します。システムは、失敗が明示的で制約された場合に信頼性が高くなり、1回の手動実行が偶然に完了する場合ではありません。

結論

チャンク転送エンコーディングは、送信が始まる前に最終バイト長が不明なボディを区切る方法という1つの正確なHTTP/1.1の問題を解決します。その16進数サイズ、データセグメント、ゼロチャンク、およびオプショナルトレーラーは、単一のホップでのトランスポートフレーミングに属します。アプリケーションは通常、デコードされたボディを消費し、オペレーターは不完全なレスポンス、プロキシ変換、またはフレーミングの競合をトレースする際にのみ生のチャンクを調査します。