知らない値の扱いが先に決まっているから、拡張できる

パスの数字をそのままステータスにする Node v24.21.0 のサーバです。

const http = require('node:http');
http.createServer((req, res) => {
  const code = Number(req.url.slice(1)) || 200;
  res.writeHead(code, { 'content-type': 'text/plain' });
  res.end(`you asked for ${code}\n`);
}).listen(Number(process.argv[2] || 18082), () => console.log('listening', process.version));

macOS の curl 8.7.1 で、/471 /400 /200 に curl -s --fail -o /dev/null -w "status=%{http_code} " …; echo "exit=$?"、続けて /471 に curl -si と curl -sS --fail を当てました。

status=471 exit=22
status=400 exit=22
status=200 exit=0
HTTP/1.1 471 unknown
content-type: text/plain
Date: Thu, 24 Sep 2026 01:53:39 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked
 
you asked for 471
exit=0
curl: (22) The requested URL returned error: 471
exit=22

471 と 400 が同じ終了コード 22 になりました。curl が 471 を 400 として読んだように見えますが、そうは言えません。手元のマニュアルは終了コード 22 をこう説明します。

The requested URL was not found or returned another error with the HTTP error code being 400 or above.

判定は「400 以上か」という数値のしきい値です。RFC の規則と結果が一致しただけで、クラス規則を実装している証拠にはなりません。なお、Node は知らない番号に理由句 unknown を付けて送りました。

RFC 8701 の対策は、使っていない値を予約し、クライアントがわざと送ることです。

To avoid this problem, this document reserves some currently unused values for TLS implementations to advertise at random. Correctly implemented peers will ignore these values and interoperate. Peers that do not tolerate unknown values will fail to interoperate, revealing the mistake before it is widespread.

Docker の headless Chromium 151 を、手元の OpenSSL 3.6.3 の s_server -trace に3回接続させました。

    ClientHello, Length=1791
    cipher_suites (len=32)
      {0xCA, 0xCA} UNKNOWN
      {0x13, 0x01} TLS_AES_128_GCM_SHA256
    extensions, length = 1686
      extension_type=UNKNOWN(10794), length=0
      extension_type=supported_versions(43), length=7
        UNKNOWN (31354)
        TLS 1.3 (772)
      extension_type=key_share(51), length=1263
          NamedGroup: UNKNOWN (39578)
          key_exchange:  (len=1): 00
  ServerHello, Length=1206
    cipher_suite {0x13, 0x01} TLS_AES_128_GCM_SHA256

10794 は 0x2A2A、31354 は 0x7A7A、39578 は 0x9A9A で、どれも RFC 8701 §2 の GREASE 値です。サーバは UNKNOWN と表示して無視し、実在の暗号スイート(暗号の組み合わせを表す2バイトの番号)を選んで握手を完了しました。key_share は鍵交換で使う値を載せる拡張で、NamedGroup はその方式の名前です。どちらも第5回『TLS 1.3 は、相手の答えを推測して1往復を削る』で扱います。ここでは、GREASE の方式名(39578)に付いた key_exchange が長さ1の 00 で、意味を読み込む値ではないことだけ押さえてください。

        暗号スイート   拡張             版       鍵交換の方式
run 1   {0xDA,0xDA}    0xFAFA 0xDADA    0x7A7A   0xCACA
run 2   {0xCA,0xCA}    0x2A2A 0x3A3A    0x7A7A   0x9A9A
run 3   {0x0A,0x0A}    0xFAFA 0x3A3A    0x4A4A   0x2A2A

値は接続ごとに変わります(§1 の advertise at random と整合)。UNKNOWN と表示された値のうち 17613(0x44CD)と 65037(0xFE0D)は GREASE 値ではない別の拡張なので、表から除きました。

一方、OpenSSL 3.6.3 の s_client の ClientHello には、2回とも GREASE 値がありませんでした。送るかどうかはクライアントの任意です(§3.1 A client MAY select one or more GREASE cipher suite values)。「TLS はランダムな値を混ぜることになっている」わけではありません。

HTTP/3 にも同じ発想の予約があります。RFC 9114 は 0x1f * N + 0x21(0x21, 0x40, 0x5f …)の形の値をフレーム型・ストリーム型・SETTINGS などに予約し、SETTINGS には少なくとも1つ入れるべき(SHOULD)としています。