フレームを送信します。圧縮コンテキストとフローコントロールは単一なのですか?シンプルにするためです。オリジナルの提案ではストリームはグループを構成でき、その中ではフローコントロールなどのコンテキストを共有することも可能でした。反面、かなり複雑度が増すことになります。解決することにしました。効率よく使うため、またはセキュリティ上の理由から、ハフマン符号化した文字列を次のバイト境界までパディングを追加します。ビットのパディングが文字列にあらわれます。ハフマン符号化だけを考えるなら、必要なパディングよりも長いシンボルならどれでもパディングとして使うことができます。デザインは、ハフマン符号化した文字列をバイト単位で比較することを許しているのです。シンボルのビット列をパディングとして使うことを要求することで、我々はハフマン符号化された文字列同士をバイト単位の比較で同一性を確認できることを保証するのです。これは多くのヘッダーはハフマン符号をデコードせずに解釈することができるということも意味するのです。実装できますか?はい、ほとんどは可能です。機能をサポートする必要はないでしょう。ついては、最初のアップグレードリクエストを実装する必要があります。対応するクライアントは、安全であり構築が容易です。レスポンスはエラーとして扱う必要があります。レスポンスと共に受け付けることができます。ステータスコードと共に拒否できます。エラーコードと共に直ちに拒否すべきです。優先度の例は間違っていませんか?いいえ。し、各ストリームの重みを重みの合計で割ります。リソースを受け取ります。必要でしょうか?はい、おそらく。単一のストリームを仕様して多くのデータをダウンロードするだけのクライアント実装であっても、最大の転送速度を得るために一部のパケットをピアに送信する必要があります。アルゴリズムを許可していれば)、1つのパケットにマージすることを可能にするために、送信パケットはしばらくの間保持されるでしょう。このようなパケットには、例えば、データを送信するために利用可能なウインドウが存在することをピアに知らせるためのパケットがあります。遅延させると、高速な接続に深刻な影響を与えます。使用するのが最も簡単でしょう。サーバープッシュは、リクエストを待つことなく、サーバーがクライアントにコンテンツを提供することを可能にします。これは、特にネットワークの往復時間のほとんどがリソースに費やす時間になるような、ネットワーク大きな帯域遅延積のコネクションにおいて、リソースの取得時間を改善できます。リクエストの内容に基づいて変化するリソースをプッシュするのは適切ではありません。プッシュされたリクエストを使用します。ヘッダーフィールドに含まれている場合であっても、全てのリクエストヘッダーフィールドの変化を尊重しません。プッシュされたリクエストが受け入れられる可能性を最大化するために、コンテンツネゴシエーションは避けたほうが良いと言えます。ヘッダーフィールドに基づくコンテンツネゴシエーションは広くキャッシュにより尊重されますが、他のヘッダーフィールドも同じようにサポートされているとは限りません。