要約

  • HTTP/1.0 の時点で 204 は、要求は完了したが新しく表示する情報がないことを示した。利用者エージェントは要求を生んだ文書表示を変えない。
  • No Content は状態やメタデータの不在ではない。現在の仕様では、ヘッダーは操作後の対象資源と選択表現を記し、PUT 後の ETag は保存された新表現を識別できる。
  • 204 はヘッダー部の終端で終わり、コンテンツも trailers も持てず、現在の HTTP は Content-Length も禁じる。空は厳密な境界である。

成功のたびに新ページは要らない

初期 Web では、操作完了と新文書表示が一組になりやすかった。取得や結果表示には自然でも、保存して編集を続ける場面には過剰である。

エディターは保存証明のため全文を受け取り直す必要がない。確認ページのために作業面を失う必要もない。必要な結果は、完了、新しい版の身元、継続の三つである。

204 はこの結果を独立した型にした。本文を失った 200 ではなく、追加コンテンツが不要だと明示する成功である。

資源を変えることと、画面の表現を置き換えることを切り離した。

HTTP/1.0 は表示の継続を規定した

1996 年 5 月の RFC 1945 は、204 を要求完了だが返す新情報がない状態とした。利用者エージェントなら、要求を発生させた文書表示を変えるべきではない。

スクリプトやその他のアクションが想定され、入力は有効になっても活動文書は動かない。エンティティーヘッダーには新しいメタ情報を載せ、その文書へ適用できた。

本文がなくても完了は弱くならない。表示が残るのも偶然ではない。この二点は最初から組になっていた。

HTTP/1.0 は 204 を本文禁止の応答にも分類した。

HTTP/1.1 は終端を空行に固定した

RFC 2068 は 1997 年に同じモデルを保ち、204 に message-body はなく、ヘッダー後の最初の空行で終了すると明記した。

1999 年の RFC 2616 は、サーバーが要求を完了し、本文は不要だが、要求されたバリアントに関する更新メタ情報を返し得るとした。エージェントは表示を保ちながら情報を反映する。

DELETE が実行済みで結果表現がない場合や、PUT で既存資源を正常変更して結果表現を返さない場合に 204 が使える。

本文の不在は処理待ちを意味しない。実行の境界は既に越えている。

204 は長さゼロの 200 ではない

空の 200 と 204 は、コンテンツのオクテット数だけなら同じことがある。意味は異なる。

通常の 200 はコンテンツが期待され、フレーミングが長さゼロを示すこともある。204 は成功結果に追加コンテンツが不要だと述べる。状態が不在の理由と、フレーミング・画面動作の前提を決める。

クライアントは期待した表現が事故で消えたのか疑わなくてよい。サーバーも 204 の後へ状態文書を付けられない。

ゼロはデータになり得る。204 は制御結果である。

ヘッダーは操作後の世界を記す

2014 年の RFC 7231 は、204 のメタデータが要求アクション適用後の対象資源と選択表現を指すと明確にした。

PUT の例では、204 の ETag は新しい表現を識別する。エディターは、保存したばかりの文書を再取得せず版マーカーを更新できる。

本文がなくても結果の身元はある。Date、キャッシュ制御などの適用可能なフィールドも意味を持つ。「204 は何もない」とヘッダーまで捨てれば、次の条件付き保存に必要な証拠を失う。

ETag は要求ペイロードそのものではなく、オリジン処理後の選択表現を説明する。

表示は残り、知識は更新できる

表示を保つことはローカル状態を古いまま凍結することではない。サーバーは、エージェントが独自 UI で成功を示し、更新メタデータを活動表現へ適用すると仮定する。

オリジンは完了と権威ある事後メタデータを管理する。エージェントは成功表示と追加取得の要否を管理する。

サーバーは全文を反響せず、クライアントは確認ページへ移動しない。それでも ETag により並行更新状態は進む。

画面が同じでも、ローカル知識は同じである必要がない。

205 は反対の画面分岐である

HTTP 205 Reset Content もコンテンツを持たないが、要求を生んだ表示を元の状態へ戻し、次の入力に備えるよう求める。

204 はリセットを求めない。保存後も文書を編集可能なままにする。204 を 205 と同じ扱いにすれば、入力や焦点、ローカル文脈を消しかねない。

「本文がない」という共通点だけでは足りない。画面制御が異なる。

全ての本文なし成功を一つの UI 分岐へ入れる実装は、プロトコルの意図的な差を失う。

202 は完了線の手前にいる

HTTP 202 Accepted は処理を受け付けたが未完了で、最終的に実行されないこともある。

HTTP 204 は正常完了を宣言する。本文がないからと再試行すれば、既に適用した操作を重ねる。非同期作業中に 204 を返せば完了時点を偽る。

支払い、削除、公開など反復に意味がある操作で違いは重大である。本文長は完了証拠ではなく、状態が証拠である。

空応答はコミットの前にも後にもある。202 と 204 が位置を示す。

ヘッダー部が応答の全てである

現在の RFC 9110 は、204 がヘッダー部の終端で終わり、コンテンツも trailers も持てず、Content-Length も送れないとする。

これは持続接続を守る。不許可の余分なバイトを、受信者によっては次メッセージの一部と解釈する可能性がある。

JSON、改行、追跡フッター、Content-Length: 0 を自動追加するミドルウェアは状態依存でなければならない。ヘッダーが終われば応答も終わる。

次のメッセージが始められる位置が、No Content の意味を保証する。

ヒューリスティックなキャッシュ性にも方法規則がある

RFC 7231 は 204 を既定でキャッシュ可能とし、RFC 9110 は方法や明示制御がない限り heuristically cacheable と表現する。

全 POST、PUT、DELETE の保存・再利用許可ではない。RFC 9111 は方法、キー、鮮度、指令へ結び付ける。

保存対象は存在しない本文より事後メタデータであることが多い。誤った要求文脈で再利用すれば、ETag を別操作へ結び付ける。

オリジンは明示的制御を出し、キャッシュは方法を含む判断を保つ必要がある。

No Content では足りない場合もある

クライアントが結果表現なしで正しく続けられるときだけ 204 は適切である。識別子、領収証、復旧トークン、競合説明、次 URI が必要な操作もある。

それを 204 の背後へ隠すのは簡潔さではなく、不完全なアプリ契約である。HTTP が省略を許しても、全省略が正しくはならない。

正規化された資源を必要とするなら再取得もできる。204 は画面遷移を要求しないだけで、後続 GET を禁じない。

送らないバイトが本当に重複しているときだけ、最小転送は成立する。

IANA が保存するのは精密な不在である

IANA HTTP ステータスコードレジストリー は 204 No Content を RFC 9110 15.3.5 に登録する。

操作成功、追加コンテンツなし、事後メタデータ、表示維持、ヘッダーで終了、という組合せである。

資源が空・不在・削除済みという意味ではない。ヘッダーを無視する許可でも、リセット命令でもない。

名前は短いが、不在の形は厳密である。

保存は画面を奪わずに完了した

204 は抑制のプロトコルである。オリジンは完了を知るが、確認ページで次の画面を支配しない。エージェントがローカルなフィードバックと作業継続を担う。

抑制は曖昧さではない。状態が完了を、ヘッダーが身元を、フレーミングが境界を固定する。

サーバーは保存し、クライアントは留まり、メタデータは進み、ネットワークは止まる。

ページが変わらないのは、何も起きなかったからではなく、もう表示するものがなかったからである。