8523
<http://syucream.github.io/hpack-spec-ja/header-compression-10-ja.html>

6.2.3 インデックスされないリテラルヘッダフィールド

の箇所に

> インデックスされないリテラルヘッダフィールド表現は 動的テーブルの変更を伴わずにデコードされたヘッダリストへの  
>  ヘッダフィールドの追加を引き起こします。 中継者はこのヘッダフィールドのエンコードに同じ表現を 使用しなければなりません (MUST) 。

とあります。  
これは「6.2.2 インデックス更新を伴わないリテラルヘッダフィールド」と何が違うのでしょうか？

> この表現は圧縮によるリスクに晒されないよう ヘッダフィールド値を保護することを意図しています (詳細は Section 7.1 を 参照)  
>  。

と書かれています。  
私はCRIME攻撃に詳しくないですが、MSBに「0001」を使用する以外はフォーマットは同じように見えます。  
なぜこれでヘッダフィールド値を保護できるのでしょうか？
CC BY-SA 3.0
2015-03-29T05:24:03.733
8522
2015-03-29T05:45:34.770
3496
question
http ssl http2 hpack
HTTP2のHPACKにおける"インデックスされないリテラルヘッダフィールド"について
§7.1.3に書かれていますが、これはセキュリティ上の理由からわざと冗長なエンコードで送信したヘッダを、プロキシサーバー側で勝手に最適化されないように通知するためのものです。

ですからプロキシサーバー側がこのヘッダーを正しく扱っていないと効果がありません。

> 7.1.3 インデックスされないリテラル
>
> ヘッダフィールドのインデックス表現の生成を止める ことは圧縮がすべてのホップで行われない場合のみ
> 影響します。インデックスされないリテラル(Section 6.2.3 を 参照) は中継者に特定の値が意図的にリテラルとして
> 送信されたことを通知するのに使用できます。中継者はインデックスを伴うインデックスされないリテラルを 使用する値を再エンコードしてはいけません (MUST
> NOT) 。
CC BY-SA 3.0
2015-03-29T05:45:34.770
8523
2015-03-29T05:45:34.770
3639
8522
answer