要約

  • RFC 9842 では、同一オリジン、URL パターン、宛先、新鮮性の条件を満たすとき、HTTP 応答を後続応答の外部圧縮辞書として扱える。
  • 辞書のハッシュ、Available-Dictionary、コンテンツ符号化の選択、キャッシュ変種、復号結果、応答の意味は別々の記録であり、一つを他の証明にしてはならない。

辞書圧縮は「すでに持っているものを使う」ため、完成した応答に近く見える。しかしクライアントが持つのは、圧縮の参照に使える過去のバイト列である。後続応答の内容、意味、権利、効果を持つわけではない。RFC 9842 はこの差を実装可能な条件として残している。

サーバーは Use-As-Dictionary により、ある応答を将来の候補辞書として広告できる。必須の match は同一オリジンの URL Pattern に制限される。match-dest は Fetch の宛先を狭め、id と type は補助情報を与える。id はクライアントにとって不透明な文字列であり、サーバーもそれを辞書内容の保証に使ってはならない。識別子は名前であって、内容の真正性や業務上の権限ではない。

次にクライアントは、保存済み辞書が新鮮か、許可された stale 状態かを確認する。送信先 URL は同一オリジンでなければならず、宛先とパターンも合う必要がある。複数候補があれば、標準の優先規則に従って一つを選ぶ。この判断が示すのは「この要求に対してこの辞書を提案できる」ということだけである。対象リソースが生成済みであること、内容が業務上正しいこと、利用者がそれを使えることは示さない。

適切な辞書を持ち、利用を選んだクライアントは、Available-Dictionary に最良候補一つの SHA-256 ハッシュを入れる。また Accept-Encoding で dcb または dcz を提示できる。これは能力の申し出であり、サーバーへの命令ではない。サーバーは通常の表現を返してもよく、別の符号化を選んでもよい。対応し、かつ利用を選ぶ場合だけ dcb または dcz を Content-Encoding として返す。

その圧縮形式に含まれる辞書ハッシュは、参照辞書と圧縮ストリームを正しく結び付ける。ここから「応答は本物だ」「利用者は理解した」「設定が反映された」とは言えない。ハッシュの一致はバイト列の対応であり、応答の意味や意思決定の正当性ではない。

キャッシュにも独自の境界がある。キャッシュ可能な辞書圧縮応答は、Accept-Encoding と Available-Dictionary で Vary しなければならない。これは未対応クライアントや別辞書のクライアントに誤った変種を渡さないためである。しかしキャッシュの変種が技術的に正しくても、権限、料金、外部状態、利用目的が現在の判断に適合するとは限らない。

セキュリティ条件も同じ結論を支える。この方式は安全なコンテキストに限定され、同一オリジンの保護を持ち、必要な緩和策が失敗すればクライアントは応答を捨てる。RFC 9842 は、公的データと秘密データを混ぜた圧縮によるサイズや時間の漏えいを警告し、辞書ハッシュを cookie と同様に分離・消去すべき追跡可能状態として扱う。HTTPS、同一オリジン、ハッシュは重要だが、認可や結果ではない。

経営のための記録は、辞書 URL とハッシュ、新鮮性、マッチ判定、クライアントの提示、サーバーの選択、Vary、キャッシュ変種、復号、応答の意味、そして別途の行為と効果を分けて保存すべきである。RFC 9842 は伝送を短くできる。だが、その短縮によって証拠の連鎖まで短くしてはならない。

出典