7. 転送コーディング (Transfer Codings)
転送コーディング名は、ネットワークを通じた「安全な転送」を確保するために、メッセージのコンテンツに適用された、適用できる、または適用する必要がある可能性のあるエンコーディング変換を示すために使用されます。これは、転送コーディングがメッセージのプロパティであるのに対し、コンテンツコーディングは転送される表現のプロパティであるという点で、コンテンツコーディングとは異なります。
すべての転送コーディング名は大文字小文字を区別せず、第 7.3 節で定義されている HTTP 転送コーディングレジストリ内に登録されるべきです。これらは、Transfer-Encoding (第 6.1 節) および TE ([HTTP] の第 10.1.4 節) ヘッダーフィールドで使用されます (後者は "transfer-coding" 文法も定義します)。
7.1. チャンク転送コーディング (Chunked Transfer Coding)
チャンク転送コーディングは、コンテンツをラップして、それぞれが独自のサイズインジケータを持つ一連のチャンクとして転送し、その後にトレーラーフィールドを含むオプションのトレーラーセクションが続きます。チャンクにより、サイズが不明なコンテンツストリームを、長さ区切りバッファーのシーケンスとして転送できるようになります。これにより、送信者は接続の永続性を保持でき、受信者はメッセージ全体を受信したことを知ることができます。
chunked-body = *chunk
last-chunk
trailer-section
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
chunk-size = 1*HEXDIG
last-chunk = 1*("0") [ chunk-ext ] CRLF
chunk-data = 1*OCTET ; chunk-size オクテットのシーケンス
chunk-size フィールドは、オクテット単位の chunk-data のサイズを示す 16 進数の文字列です。チャンク転送コーディングは、chunk-size が 0 のチャンクを受信したときに完了します。これには、トレーラーセクションが続き、最後に空行で終了します。
受信者は、チャンク転送コーディングを解析およびデコードできなければなりません (MUST)。
HTTP/1.1 は、中継装置が全体のレスポンスをバッファリングできることを保証できるように、チャンクレスポンスのサイズを制限する手段を定義していません。さらに、非常に大きなチャンクサイズは、受信実装でその値が正確に表現されない場合、オーバーフローや精度の損失を引き起こす可能性があります。したがって、受信者は、潜在的に大きな 16 進数を予測し、整数変換オーバーフローまたは整数表現による精度損失による解析エラーを防止しなければなりません (MUST)。
チャンクコーディングはパラメータを定義しません。その存在はエラーとして扱われるべきです (SHOULD)。
7.1.1. チャンク拡張 (Chunk Extensions)
チャンクコーディングにより、各チャンクは、chunk-size の直後に 0 個以上のチャンク拡張を含めることができます。これは、チャンクごとのメタデータ (署名やハッシュなど)、メッセージ中間制御情報、またはメッセージ本文サイズのランダム化を提供するためです。
chunk-ext = *( BWS ";" BWS chunk-ext-name
[ BWS "=" BWS chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token / quoted-string
チャンクコーディングは各接続に固有であり、より高レベルのアプリケーションが拡張を検査する機会を得る前に、各受信者 (中継装置を含む) によって削除または再コードされる可能性があります。したがって、チャンク拡張の使用は一般的に、"ロングポーリング" などの特殊な HTTP サービスに限定されます (クライアントとサーバーがチャンク拡張の使用に関して共有の期待を持つことができる場合)、またはエンドツーエンドのセキュアな接続内のパディング用です。
受信者は、認識できないチャンク拡張を無視しなければなりません (MUST)。サーバーは、メッセージの他の部分に長さ制限とタイムアウトを適用するのと同じ方法で、リクエストで受信したチャンク拡張の合計長を提供されるサービスに合理的な量に制限し、その量を超える場合は適切な 4xx (Client Error) レスポンスを生成すべきです。
7.1.2. チャンクトレーラーセクション (Chunked Trailer Section)
トレーラーセクションにより、送信者は、コンテンツの送信中に動的に生成される可能性のあるメタデータをチャンクメッセージの最後に含めることができます。例えば、メッセージ完全性チェック、デジタル署名、または処理後のステータスなどです。トレーラーフィールドの適切な使用と制限は、[HTTP] の第 6.5 節で定義されています。
trailer-section = *( field-line CRLF )
メッセージからチャンクコーディングを削除する受信者は、受信したトレーラーフィールドを選択的に保持または破棄してもかまいません (MAY)。受信したトレーラーフィールドを保持する受信者は、トレーラーフィールドを受信したヘッダーフィールドとは別に保存/転送するか、受信したトレーラーフィールドをヘッダーセクションにマージしなければなりません (MUST)。受信者は、対応するヘッダーフィールド定義が明示的に許可し、トレーラーフィールド値を安全にマージする方法を指示していない限り、受信したトレーラーフィールドをヘッダーセクションにマージしてはなりません (MUST NOT)。
7.1.3. チャンクのデコード (Decoding Chunked)
チャンク転送コーディングをデコードするプロセスは、疑似コードで次のように表すことができます:
length := 0
chunk-size、chunk-ext (存在する場合)、および CRLF を読み取る
while (chunk-size > 0) {
chunk-data と CRLF を読み取る
chunk-data をコンテンツに追加
length := length + chunk-size
chunk-size、chunk-ext (存在する場合)、および CRLF を読み取る
}
トレーラーフィールドを読み取る
while (トレーラーフィールドが空でない) {
if (トレーラーフィールドが別々に保存/転送される) {
トレーラーフィールドを既存のトレーラーフィールドに追加
}
else if (トレーラーフィールドが理解され、マージ可能と定義されている) {
トレーラーフィールドを既存のヘッダーフィールドとマージ
}
else {
トレーラーフィールドを破棄
}
トレーラーフィールドを読み取る
}
Content-Length := length
Transfer-Encoding から "chunked" を削除
7.2. 圧縮用転送コーディング (Transfer Codings for Compression)
圧縮用の次の転送コーディング名は、対応するコンテンツコーディングと同じアルゴリズムで定義されます:
compress (および x-compress) : [HTTP] の第 8.4.1.1 節を参照。
deflate : [HTTP] の第 8.4.1.2 節を参照。
gzip (および x-gzip) : [HTTP] の第 8.4.1.3 節を参照。
圧縮コーディングはパラメータを定義しません。これらの圧縮コーディングのいずれかでのパラメータの存在は、エラーとして扱われるべきです (SHOULD)。
7.3. 転送コーディングレジストリ (Transfer Coding Registry)
"HTTP 転送コーディングレジストリ" は、転送コーディング名の名前空間を定義します。これは https://www.iana.org/assignments/http-parameters で管理されています。
登録には次のフィールドが含まれなければなりません (MUST):
- 名前
- 説明
- 仕様テキストへのポインター
転送コーディングの名前は、第 7.2 節で定義されている圧縮コーディングのように、エンコーディング変換が同一である場合を除き、コンテンツコーディングの名前 ([HTTP] の第 8.4.1 節) と重複してはなりません (MUST NOT)。
7.4. 転送コーディングのネゴシエーション (Negotiating Transfer Codings)
TE ヘッダーフィールド ([HTTP] の第 10.1.4 節) は、リクエストで使用され、チャンク以外に、クライアントがレスポンスで受け入れる意思のある転送コーディング、およびクライアントがチャンク転送コーディングでトレーラーフィールドを保持する意思があるかどうかを示します。
クライアントは、TE でチャンク転送コーディング名を送信してはなりません (MUST NOT)。チャンクは HTTP/1.1 受信者にとって常に受け入れ可能です。