要約

  • 1997年のHTTP/1.1は、処理済みの要求に対して入力画面を元に戻す応答として205 Reset Contentを定めた。
  • この応答は新しい本文を運ばない。2014年と2022年の仕様は、フォームなどの再入力場面と、空の応答の終端を明確にした。

窓口で記入済みの用紙を渡す。係員は受け取り、目の前にはすぐ新しい白紙が置かれる。手続きは終わったのに、作業机は出発点に戻った。1990年代のHTTPは、この少々せっかちな応対を205 Reset Contentという成功コードにした。

1997年1月のRFC 2068では、サーバーは要求を処理済みで、ユーザーエージェントはその要求を起こした文書の表示をリセットすべきだとする。想定されたのは入力フォームだ。書き込んで送信し、欄を空け、次の入力に移る。完了を記録する側と、手元の入力欄を整える側は別々である。205は一つの応答でその両方をつないだ。

初期化されるのは利用者の作業面だ。送信済みの情報は要求としてサーバーに届いている。仕様は205の応答にエンティティを含めることを禁じた。次に表示する新しいページを渡す代わりに、すでに開いている文書の扱いを状態コードで指示したのである。窓口の係員が控えを保存しながら、記入台だけを拭くような仕組みだった。

1999年6月のRFC 2616も、送信後にフォームを消して次の入力をしやすくする説明を維持した。隣の204 No Contentは、作業中の表示をそのまま残す。どちらも本文を返さないが、画面に求める動きが違う。205が得意なのは反復作業だ。一件が済むたびに画面を差し替えるのではなく、同じ入力場所を次の一件のために整える。

2014年のRFC 7231は、戻る先を「オリジンサーバーから受け取った当初の状態」と表現した。例もフォームだけにとどまらず、メモ帳やキャンバスに広がる。利用者がそこに書き込み、操作し、送信してから、次の作業のために初期状態へ戻す。HTTPの応答が扱っていたのはデータの往復だけではない。人の手順にも小さな区切りを付けていた。

応答の中身が空なら、通信上の終わり方ははっきりさせなければならない。同じ2014年の仕様は、205がペイロードを生成しないと定め、長さを示す三つの方法を並べた。Content-Length: 0、長さゼロの最後のチャンク、あるいはヘッダーの終了直後に接続を閉じる方法だ。記入台が空になる前に、受信側はまず空のメッセージの終端を読み取る。

2022年のRFC 9110でも筋書きは同じだ。サーバーの処理は完了し、ユーザーエージェントは元の表示状態へ戻ることを求められ、応答には追加の内容がない。番号は、入力を一回限りのイベントではなく、続いていく作業として捉えている。

成功した仕事はサーバー側に残る。画面上の余白は新しくなる。205が用意したのは、完了を祝う盛大なページではなく、次の用紙だった。列が長い窓口では、その簡潔さにも立派な意味がある。