要約

  • 1997年1月のRFC 2068は、HTTP/1.1に402 Payment Requiredを載せた直後、「将来の使用のために予約」と定めた。
  • RFC 2616、RFC 7231、RFC 9110もその予約を引き継いだ。HTTPには今も、価格、支払いの提示、決済確定を共通化する402の規則がない。

番号札はある。レジはない。

RFC 1945はHTTP/1.0のステータスコードを、要求の結果を機械向けに伝える値として説明し、当時認識されていたコードを列挙した。クライアントエラーの並びは401 Unauthorizedから403 Forbiddenへ進み、402はその一覧にない。拡張コードは認められていたため、未掲載番号を拡張として使う余地はあった。RFC 1945自身が402に意味を与えたわけではない。 RFC 1945 §§6.1.1–6.1.2

1997年1月のHTTP/1.1仕様RFC 2068は、ステータスコードの文法に402を加え、第10.4.3節を割り当てた。規則は一文だけだった。「This code is reserved for future use.」料金の門を示す名前は付いた。門の先で何をやり取りするかは書かれなかった。 RFC 2068 §§6.1.2, 10.4.3

コードは処理結果の種類を示せても、取引の中身までは運べない。402の定義には金額、通貨、受取人、支払い証明、確認、決済、異議申立ての方法がない。サーバーは本文で独自条件を説明できるが、HTTPはそれを異なるクライアントやサービス間で使える規則にしていない。

401にはチャレンジがあり、402には待合札がある

隣の401は、共通のやり取りを標準にする方法を示す。RFC 9110は、401応答に適用可能な認証チャレンジを少なくとも一つ含むWWW-Authenticateを要求する。クライアントは方式を読み、必要な資格情報を選べる。第15.5.3節の402には同種の指示がなく、将来用という予約だけがある。 RFC 9110 §§15.5.2–15.5.3

その空白を埋めるのはアプリケーションだ。アクセスを支払い条件にするサービスは、金額、買い手の支払い証明、受取先、証明や決済が失敗したときの処理を自分で決める。HTTPは拒否の札を出す。レジと領収書と失敗時の手順は、サービス側が実装する。

「未来」は版をまたいで延長された

1999年6月のRFC 2616は、第10.4.3節で同じ予約を繰り返した。2014年のRFC 7231も、2022年のRFC 9110も同じだった。節番号は変わっても、支払いの規則は入らない。HTTPの意味論を更新するたび、402の空欄は次の版へ引き継がれた。 RFC 2616 §10.4.3 · RFC 7231 §6.5.2

RFCは、著者がどの決済方式を想定したかを記していない。想定方式を特定する同時代の設計記録が見つかれば、由来の説明は変わる。公刊された規格から確認できるのは名称と予約であり、空欄が生まれた理由ではない。

この記事の確認時に参照したIANA登録簿は2025年9月15日更新で、402を「Payment Required」と記載し、RFC 9110の15.5.3節を参照先にしている。IANA HTTP Status Code Registry

実装費用は開発チームへ戻る

ここに開発者向けインターフェースの経済性が表れる。共通プロトコルがあれば、各チームが同じ取引手順を別々の文書で交渉せずに済む。HTTPの402はその負担を減らさない。購入者側のクライアントとサーバーは、価格、証明、資格情報、再試行、決済完了をアプリケーション層で合意する。統合と保守の負担は開発チームが持ち、各サービスは条件を決める権限を保つ。

402は状況の名前であって、決済インターフェースではない。支払いがアクセス条件だと知らせても、条件を満たす共通手順は渡さない。HTTPのレジは、標準番号を掲げた各サービスのローカルルールだ。

出典