要約

  • 1997年のHTTP/1.1は305 Use Proxyで、Locationに示すプロキシ経由で同じ要求をやり直すよう受信者に求めた。
  • 1999年の改訂は一回の要求とオリジンサーバーに範囲を絞り、2014年の改訂は応答の中でプロキシを設定することへの安全上の懸念から非推奨にした。

目的地に道を尋ねたら、「まず私が選んだ仲介人に会ってください」と返された。その仲介人の住所まで添えてある。初期のHTTPには、これを状態コードにした305 Use Proxyがあった。サーバーの応答がクライアントの次の通り道を指図する。行き先の案内というより、道路上の受付係を増やす提案である。

1997年1月のRFC 2068は、要求した資源にLocationで指定されたプロキシを通じてアクセスし、受信側がその経路で要求を繰り返すと記した。同じRFCでプロキシは、要求を受け取り、必要に応じてメッセージを組み替え、先へ送る転送者として説明される。案内板の先には、実際に通信を受け取る機械がある。

普通の引っ越しを知らせる301なら、資源の新住所を示す。305が選ぼうとしたのは元の資源へ行く途中の中継地点だ。クライアントには自身のネットワーク設定や信頼する経路がある。その選択に、目的地から返った一つの応答が入り込む。指示の期間と発信できる主体を明記しないままでは、通行人が案内板を立て直せてしまう。

1999年6月のRFC 2616は二つの境界を追加した。305が対象にするのはその一回の要求だけであり、生成できるのはオリジンサーバーだけ。付記は、RFC 2068がこの二点を明確にしておらず、守らない場合には重大なセキュリティ上の結果が生じると述べる。一度の応答が将来のすべてのプロキシ設定にならないようにし、中継者が次の中継者を勝手に任命する道も狭めた。

それでも応答の中でプロキシを設定する仕組みは残った。2014年のRFC 7231は305を非推奨とし、改訂点の一覧で理由を明示した。HTTPのやり取りの内側でプロキシを設定することへのセキュリティ上の懸念である。問題の中心には、次の要求を受け取る中継者をHTTPの応答自身が指定する仕組みがあった。

2022年のRFC 9110にも305の番号は残るが、説明は非推奨である。古い記録を読めるよう、廃止された路線の番号が時刻表の欄に置かれている。番号を知ることと、その道順に従うことは別だ。

プロキシは目的地の手前で要求を受け取る。そこを通るかどうかは単なる行き方の好みでは済まない。305は目的地から来た返事にその選択権を持たせようとし、1999年に柵を付けられ、2014年に路線ごと退いた。誰が途中の席を指定できるか。小さな状態コードは、その権限がいかに大きいかを見せた。