[213] 205 は、送信元のフォームの再設定を行うことを指示する状態符号でした。
[214] かつては一部の Webブラウザーが実装していましたが、 広く実装・利用されるに至らず、事実上の廃止状態にあります。
[209] 205 は、鯖が要求の処理を満足し、
利用者エージェントが本要求を送信させることとなった「文書表示」
を起源鯖から受信した元の状態に戻すべきであることを示します >>207。
[211] 鯖は、 payload を生成してはなりません。
Content-Length: 0 とするか、
Transfer-Encoding: chunked によって長さを0とするか、
ヘッダーの直後の改行の直後で接続を閉じるかのいずれかとしなければなりません。
>>207
[208] RFC 2068・2616 (HTTP/1.1) +10.2.6 205 Reset Content
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.
サーバーは要求を満たし、利用鎖へージェントはその要求の送信を引き起こした文書表示を再設定するべきです。 この応答は、主として、後で入力が与えられた入力欄の消去によって利用者が用意に次の入力動作を初期化できるような種の、利用者の入力によって起こる動作の入力を可能とすることを意図しています。 応答は実体を含んでいてはなりません。
[1] あんまり良い使用例は思い浮かびませんが、 例えば Web chat で、2つのフレームがあったとします。 フレーム1は入力 (発言) 欄、 フレーム2は会話内容が表示されるものであるとします。 そして、フレーム2は一定時間おきに再読み込みされます。
で、フレーム1で入力後、送信すると、 205
を返せば、フレーム1の表示はそのままですが、
フレーム1で今入力してた発言は消去され、
次の発言の準備ができます。フレーム2はフレーム1には影響されず、
相変わらず一定時間おきに更新されます。
フレーム1送信直後の表示ではフレーム1で送信した発言が追加されていることでしょう。
現存の Web chat の実装のほとんどではフレーム1の初期化は JavaScript で実装していたりしますし、 204 や 205 を知らないので発言時に target=フレーム2 にしてフレーム2を最新版に更新するわけですが、そういうのをなくして処理を単純化できます。
Web chat いくない! という話は勘弁して。
204の場合はヘッダーの直後の改行でメッセージが終わることになっていますが、205の場合は改行で終わらず、その後に payload body が続くことになっています。