共有する表は、届く順序を要求する

Python の hpack 4.2.0(Docker の python:3.12-slim、Python 3.12.14)で、同じ5つのヘッダを同じエンコーダで2回符号化し、2回目だけを新しいデコーダに渡しました。

import sys, importlib.metadata as md
import hpack
from hpack import Encoder, Decoder
print("python", sys.version.split()[0], "hpack", md.version("hpack"))
headers = [(":method","GET"),(":scheme","https"),(":authority","example.com"),(":path","/index.html"),("user-agent","l11-demo/1.0")]
enc = Encoder()
b1 = enc.encode(headers)
b2 = enc.encode(headers)
print("1st block:", len(b1), "bytes", b1.hex())
print("2nd block:", len(b2), "bytes", b2.hex())
d = Decoder()
print("in-order decode 1st:", d.decode(b1))
print("in-order decode 2nd:", d.decode(b2))
fresh = Decoder()
try:
    print("fresh decoder, 2nd only:", fresh.decode(b2))
except Exception as e:
    print("fresh decoder, 2nd only -> exception:", type(e).__module__ + "." + type(e).__name__, "|", e)

python 3.12.14 hpack 4.2.0
1st block: 24 bytes 828741882f91d35d055c87a7857a89a0215a42d27602b83f
2nd block: 5 bytes 8287bf85be
in-order decode 1st: [(':method', 'GET'), (':scheme', 'https'), (':authority', 'example.com'), (':path', '/index.html'), ('user-agent', 'l11-demo/1.0')]
in-order decode 2nd: [(':method', 'GET'), (':scheme', 'https'), (':authority', 'example.com'), (':path', '/index.html'), ('user-agent', 'l11-demo/1.0')]
fresh decoder, 2nd only -> exception: hpack.exceptions.InvalidTableIndex | Invalid table index 63

名前と値を合わせて81バイトのヘッダが、1回目は24バイト、2回目は5バイトになりました。ただしこの数字はヘッダの組と Huffman 符号(文字列を短く詰める固定の符号表。RFC 7541 §5.2)の有無で変わります。同じ組を huffman=False で符号化すると1回目は30バイト、2回目は同じ5バイトでした。2回目が5バイトなのは、5つとも表の参照1バイトで済んだからです。

2回目の5バイトを読むと、先頭ビットが1(表の参照)で、下位7ビットが番号です。

バイト  番号  指す表      中身
82      2     静的表      :method: GET
87      7     静的表      :scheme: https
bf      63    動的表      :authority: example.com
85      5     静的表      :path: /index.html
be      62    動的表      user-agent: l11-demo/1.0

順に処理したデコーダは、1回目で動的表に2項目を足しているので62と63を引けます。新しいデコーダの動的表は空なので、最初の動的参照63で止まりました。

この「新しいデコーダ」は、1回目を受け取り損ねた受け手の模型です。実際の HTTP/2 では TCP が順序を保つので、この形の失敗は起きません。復号に失敗すれば、RFC 9113 §4.3 は接続全体のエラー(COMPRESSION_ERROR)として扱うよう定めています。表が接続全体で1つだからです。

RFC 9204 §5 が定める設定は2つで、どちらも既定値は0です。

設定                                意味                        既定値
SETTINGS_QPACK_MAX_TABLE_CAPACITY   動的表の容量                0
SETTINGS_QPACK_BLOCKED_STREAMS      待たせてよいストリームの数  0

容量が0なので、何も宣言しなければ動的表そのものを使いません。待たせてよい数は受け手が上限を宣言し、送り手はそれを守らなければなりません(§2.1.2 An encoder MUST limit the number of streams that could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times.)。

受け手が1以上を宣言した場合に限り、確認前の項目を参照でき、損失や順序の入れ替わりがあればそのストリームが待つことがあります(§2.1.2 the stream can become blocked at the decoder)。待つのは、その参照を含むストリームです。

RFC 9204 §1 は設計目標を substantially less head-of-line blocking under the same loss conditions と書いています。ゼロとは書いていません。待ちが起きうる上限は受け手が決め、その内側で危険を取るかは送り手が決めます。

この QPACK の挙動は仕様の記述から読んだもので、手元の実演はしていません。