RFC 9110: HTTPセマンティクス

このRFCが決めたこと

横にスクロール

RFC 9110（2022年6月、STD 97）は、HTTPというプロトコルの「意味」だけを取り出して定義した文書だ。リクエストやレスポンスがネットワーク上でどう表現されるか（メッセージ構文）はHTTP/1.1・2・3で異なる（HTTPのバージョンを参照）が、GETが何を意味するか、404が何を表すかといった意味論は、すべてのバージョンで共通する。9110はこの共通部分を一手に担う。

かつてHTTP/1.1はRFC 2616、のちにRFC 7230〜7235へと分割されていた。9110はそのうち意味論（旧7231・7232・7233・7235と、7230の意味論部分）を統合し、バージョン固有のメッセージ構文はRFC 9112（HTTP/1.1）・9113（HTTP/2）・9114（HTTP/3）へ、キャッシュはRFC 9111へと切り分けた。

要点の精読

メソッドと安全性・冪等性

メソッドには安全（safe）と冪等（idempotent）という2つの性質がある。安全とは、そのリクエストがサーバー状態の変更を意図しない読み取り専用の操作であること。冪等とは、同じリクエストを複数回送っても、1回だけ送ったのと同じ効果になることだ。定義上、安全なメソッドは必ず冪等でもある。

PUTは「この内容で置き換える」ので何度実行しても最終状態は同じ（冪等）だが、状態を変えるため安全ではない。POSTはどちらでもないため、送信の再試行が二重登録を生む恐れがあり、実装で最も注意を要する。

ステータスコードの5クラス

ステータスコードは先頭の数字で5つのクラスに分かれる。1xx情報、2xx成功、3xxリダイレクト、4xxクライアントエラー、5xxサーバーエラー。クラスの意味自体が規定されているので、未知のコード（例えば299）を受け取っても、クライアントはクラス単位で扱いを判断できる。

条件付きリクエストとレンジ

条件付きリクエストは、ETagやLast-Modifiedという「バリデータ」を使い、リソースが変わっていなければ本体の転送を省く仕組みだ。If-None-Matchがサーバー側のETagと一致すれば、304 Not Modifiedが本体なしで返る。

GET /style.css HTTP/1.1
If-None-Match: "abc123"

HTTP/1.1 304 Not Modified
ETag: "abc123"

レンジ取得はRangeヘッダで一部だけを要求し、206 Partial Contentで返す。これらはHTTPキャッシュや再開可能ダウンロードの基盤になっている。

認証の枠組み

9110は特定の認証方式ではなく、チャレンジ／レスポンス型の枠組みを定める。サーバーは401 UnauthorizedとWWW-Authenticateヘッダで認証スキームを提示し、クライアントはAuthorizationヘッダで応答する。方式の詳細はセキュリティ側の話題だが、その土台となる約束事はここにある。

つまずきやすい点

まず、安全と冪等の混同に注意したい。安全は冪等の一部（安全⊂冪等）であり、PUT/DELETEは冪等だが安全ではない。次に、401と403は別物だ。401は「認証されていない（やり直せる）」、403は「認証済みでも許可されない」を意味する。もう一つ、9110はリソースと、その表現（representation）を区別する。Content-Typeなどが記述するのは、あくまで表現のメタデータであって、リソースそのものではない。

まとめ

RFC 9110は、HTTPの意味論をバージョンから独立させた土台だ。メソッドの性質、ステータスのクラス、条件付きリクエスト、認証枠組みを一度理解すれば、HTTP/1.1でも2でも3でも同じ知識が通用する。HTTPの他のRFC解説はRFC精読から辿れる。