16

チャンクHTTP転送エンコーディングを使用する場合、サーバーがチャンクサイズをバイト単位で書き出し、後続のチャンクデータをCRLFで終了する必要があるのはなぜですか。

これにより、バイナリデータの送信が「CRLF-unclean」になり、メソッドが少し冗長になりませんか？

データのどこかに0x0Aの後に0x0Dが続く場合（つまり、これらは実際にはデータの一部です）はどうなりますか？クライアントは、チャンクの先頭に明示的に指定されたチャンクサイズを順守するか、データで最初に検出されたCRLFをチョークすることが期待されますか？

これまでのところ、予想されるクライアントの動作について理解しているのは、サーバーから提供されたチャンクサイズを取得し、次の行に進み、次のデータ（CRLFまたはCRLFなし）からこの量のバイトを正確に読み取り、CRLFをスキップすることです。データに従い、チャンクがなくなるまで手順を繰り返します。これは準拠した動作ですか？もしそうなら、各データチャンク後のCRLFのポイントは何ですか？読みやすさ？

私はこれについていくつかのWeb検索を行い、HTTP 1.1仕様の読み取りも行いましたが、決定的な答えは私にはわかりません。

4

2 に答える 2

28

チャンク コンシューマーは、CRLF ペアのメッセージ本文をスキャンしません。最初に指定されたバイト数を読み取り、次にさらに 2 バイトを読み取り、CR と LF であることを確認します。そうでない場合は、メッセージ本文の形式が正しくなく、サイズが正しく指定されていないか、データが破損しています。

末尾の CRLF はベルトとサスペンダーの保証 ( RFC 2616 セクション 3.6.1、Chunked Transfer Codingによる) ですが、フィールドが行の先頭から始まるという一貫したルールを維持するためにも役立ちます。

于 2010-01-24T16:17:16.827 に答える
6

各チャンクの後の CRLF は、各チャンクの先頭のチャンク サイズが原因で必要ないため、おそらく読みやすくするためのものです。ただし、チャンク サイズの後に追加情報がある可能性があるため、「チャンク ヘッダー」の後の CRLF が必要です (「チャンク転送エンコーディング」を参照)。

      chunk          = chunk-size [ chunk-extension ] CRLF
                       chunk-data CRLF
于 2010-01-24T16:05:45.023 に答える