9

HTTP/2 では、接続固有のヘッダー フィールドが禁止されています。次のヘッダー フィールドは表示してはなりません: "Connection"、"Keep-Alive"、"Proxy-Connection"、"Transfer-Encoding"、および "Upgrade"。さらに、「TE」ヘッダー フィールドには、「トレーラー」以外の値を含めてはなりません。

HTTP/2 では Transfer-Encoding ヘッダーが禁止されているため、HTTP/2 プロキシはヘッダー Tranfer-Encoding: chunked をどのように処理するのでしょうか?

プロキシは常にチャンクされたリクエスト全体をメモリにキャッシュし、Content-Length ヘッダーを追加して、HTTP/2 サーバー/クライアントに送信する必要がありますか?

4

1 に答える 1

16

HTTP/2 では、コンテンツは常に「チャンク」されます。これは、コンテンツが DATA フレームで送信されるためです。つまり、フレームが最後のフレームであるかどうかを通知する end-of-stream フラグとともにブロック長を運ぶバイトのブロックです。

HTTP/2 から HTTP/1.1 へのプロキシでは、プロキシにはいくつかの選択肢があります。

非常に単純なケースは、受信した各 HTTP/2 DATA フレームを再マップし、それを HTTP/1.1 チャンクとして送信することです。したがって、プロキシはTransfer-Encoding: chunked通信の HTTP/1.1 側にヘッダーを追加する必要があります。同様に、読み取った各コンテンツを DATA フレームに再マップできます (チャンクが大きい場合にチャンク全体を待機/バッファリングするのとは対照的に)。

もう 1 つのケースは、受信した DATA フレームの一部をバッファリングして、それらの 1 つにストリーム終了フラグが設定されていることを期待することです。これが発生すると、コンテンツ全体の長さがわかり、プロキシはContent-Lengthヘッダーを追加して、コンテンツ全体を一度に送信できます。

また、前のケースでは、バッファがオーバーフローしたときに、プロキシはヘッダーを追加しTransfer-Encoding: chunked、バッファのサイズのチャンクを送信できます (最初のケースのような DATA フレームのサイズではありません)。

プロキシは最後の DATA フレームを受信すると、残りのバイトをチャンクに分割し、ターミナル チャンク (チャンクの終わりを知らせる長さ 0 のチャンク) を送信します。

HTTP/1.1 から HTTP/2 への逆方向では、プロキシがチャンク化されたコンテンツを受信すると、単純にTransfer-Encoding: chunkedヘッダーを破棄し、受信したチャンクから DATA フレームを作成して、そのフレームを送信できます。最終的に、端末チャンク (チャンクの終わりを知らせる長さゼロのチャンク) を受信し、ストリームの終わりフラグが設定された長さゼロの DATA フレームに変換します。

もちろん、プロキシによって実行されるバッファリングまたはその他の最適化がある場合、DATA フレーム サイズはチャンク サイズと正確に等しくない場合があります。

HTTP/2 がストリームの終わりフラグを含む DATA フレームを送受信するという事実のおかげで、プロキシは HTTP/1.1 との間で簡単に変換でき、ストリームの終わりの DATA フレームをターミナル チャンクにマッピングし、端末チャンクをストリームの終わりのDATAフレームに。

于 2015-04-07T09:06:00.577 に答える