対応するHTTPパイプラインリクエストと一致するHTTP応答

Question

HTTPリクエストと対応する応答を照合するプログラムを作成しようとしています。ほとんどのシナリオ（TCPシーケンス番号を使用して転送が完全に順序付けられている場合でもそうでない場合でも）がすべて正常に機能しているようです。

私が見つけた唯一の問題は、パイプラインリクエストがあったときです。その後、いくつかの回答が得られますが、どのパケットが特定の要求に対する回答か、どの回答がないかはわかりません。私は応答が順次来て、このプロパティをContent-Lengthフィールドの情報と組み合わせることが解決策であると思われる別の記事を読んでいます。問題は、Content-lengthは必須フィールドではないため、私がいつもそれに依存できるかどうかはわかりません。

この機能をサポートしているWebブラウザ（btw、ほとんどの場合はそうではありません）が実際にどのように機能しているか知っていますか？

Answer 1

本文の長さに関する情報がヘッダーに存在する必要があります。それはちょうど「内容長」にあるとは限らない。パイプライン化すると

：
Aがすべてをうまくするためには、関連するRFC 2616最も顕著な部分異なるヘッダと4.4取引RFC 2616から

いくつかのより関連性のルールを勉強する必要がありますサーバは、要求が受信されたのと同じ順序でそれらの要求に応答を送信しなければならない（MUST）。 9.2
から

を応答本体が含まれていない場合、応答が「0」のフィールド値とのContent-Lengthフィールドを含まなければなりません。 10.2.7 206部分コンテンツから

応答は、....のContent-Rangeヘッダフィールド...又はマルチパートのいずれかを含まなければなりません/ byteranges各パーツのコンテンツレンジフィールドを含む のContent-Type 。これはセクション4.4の規則によって禁止されない限り

のContent-Length 14.13からアプリケーションは、メッセージボディの転送長さを示すためにこのフィールドを使用すべきです。

Answer 2

現在の回答は少し古いです。リフレッシュが必要です。

新しいHTTP 1.1 RFCはRFC 7230です。また、メッセージサイズの解析に関するより正確な情報が含まれています。メッセージのサイズを検出Associating a response to a request

Security Considerations

Message Body Length

• は非常に複雑です。 Content-length、またはTransfer-Encoding: chunked、またはその両方、またはその両方を持つことができます。 100 Continueのような一部のコードでは、これをすべて変更する可能性があります。

  最初のリンクは右のサイズを推測する権利ためにチェックすべき7つの項目が含まれています。

  最後のリンクに記載されているとおり、正しいメッセージの長さを検出できないと、HTTPのスマグリング（分割、キャッシュポイズニング）問題が発生する可能性があります。

  パイプラインサポートは、密輸問題の原因のほとんどです。 RFC7230のドキュメントを実装したい場合は、本当にそれをすべて処理してください。