[519] 204 (No Content) は、処理が成功したことと、 payload body が無いことを表す状態符号です。

仕様書

意味

[513] 204 は、鯖が要求を成功裏に満足し、 応答の payload body に入れて送信する追加情報はないことを示します。 >>512

[514] 応答ヘッダーのメタデータは対象資源と、 要求された動作の適用後の選択された表現についてのものです。 >>512

[515] 例えば PUT 要求に 204 応答が返され ETag: ヘッダーが含まれている場合、 PUT が成功だったことを表し、 ETag: の値は対象資源の新しい表現の実体タグとなります >>512。

構文

[206] 204 応答は、メッセージ本体を持ちません >>205。 ヘッダーの後の最初の改行でメッセージが終わります >>12。

文脈

[511] 起源鯖は、対象資源が現在表現を持っており、 PUT によりその編集に成功した場合には、 200 か 204 を送信しなければなりません >>507。

[218] 起源鯖は、処理が成功した場合には、 処理が成功するであろうものの実施されていない場合には 202 を、 実施され追加情報は特に無い場合には 204 を、 実施され応答メッセージに状態を説明する表現を含める場合には 200 を返すべきです >>215。

[6] COPY 要求 >>5 や MOVE 要求 >>8 によって既存の終点資源が上書きされた場合には、 204 応答を返します。

[7] DELETE 要求に対する 207 応答内の status 要素では使うべきではありません >>4。

[10] ULOCK 要求が成功した場合、 204 応答を返すことができます。 200 より 204 が適切です。 >>9

[12] LER は 204 を返すことができます >>11。

[3] Prefer: return=minimal が指定された場合の応答としても利用できます。

処理

[516] 利用者エージェントは利用者に適当な方法で成功を示し、 また新規や更新されたメタデータが含まれていれば (利用者エージェントが保持しているキャッシュなどの) 表現にも適用することが期待されています >>512。

[517] 例えば文書を編集していて「保存」する時に、 保存しつつ利用者がそのまま編集を継続できるようにするために 204 が使われます >>512。

[518] 204 応答は、キャッシュ可能です >>512。

歴史

[207] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 10.2.5 204 No Content

The server has fulfilled the request but {1945,2068} there is no new information to send back {2616} does not need to return an entity-body, and might want to return updated metainformation. {1945,2068} If the client is a user agent, it {1945} should not {2068} SHOULD NOT change its document view from that which caused the request to be {1945} generated {2068} sent. This response is primarily intended to allow input for {1945} scripts or other actions to take place without causing a change to the user agent's active document view. The response {1945} may {2068} MAY include new {2616} or updated metainformation in the form of {1945} entity headers {2068,2616} entity-headers, which {1945} should {2068} SHOULD {1945,2068} apply to the document currently in the user agent's active view {2616} if present SHOULD be associated with the requested variant.

サーバーは要求を満たしましたが、送り返すあたらしい情報はありません entity-body を返す必要はなく、更新されたメタ情報を返すことを望んでいるかもしれません。 応答は新規の又は更新されたメタ情報を実体頭欄の形で含んでいてもよく、示されている場合は要求した変種と関連付けられるべきです。。

{2616} If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.

クライアントが利用者エージェントであれば、 要求を送ることとした文書表示を変更するべきではありません。 この応答は主として利用者エージェントの活性文書表示を変更することなく起こる動作の入力を可能とすることを意図しています。 但し、新規の又は更新されたメタ情報は、現在利用者エージェントで活性表示中の文書に適用するべきです。

{206,2616} The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

204 応答は message-body を含んではならず、 従って常に頭欄の後の最初の空行で終端します。

メモ

[1] 駄目駄目な UA は、 204 が返っても読み込み中のままになったりします。

また、例えばボタンの押下によって利用者が画面表示上の変化を期待していそうな場合なんかは、 表示に変化が起こらないとすると利用者が戸惑って何度も押してしまったりするかもしれません。

その辺、資源の著者や UA の作者の配慮でうまく問題を回避して欲しいです。。。

[2] >>1 最低でも、 UA は読み込みを終了して、状態棒にサーバーが要求を受け入れましたみたいなメッセージを出して欲しいですね。

[208] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) http://tools.ietf.org/html/rfc7252#section-5.9.1.4

[520] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.3

[13] head :no_content (204 status code) returns error · Issue #510 · Alamofire/Alamofire ( ()) https://github.com/Alamofire/Alamofire/issues/510

[14] RFC 7967 - Constrained Application Protocol (CoAP) Option for No Server Response () https://tools.ietf.org/html/rfc7967

[15] RFC 7967 - Constrained Application Protocol (CoAP) Option for No Server Response () https://tools.ietf.org/html/rfc7967#section-3.4

[16] Under-specified: parsing behavior following 204 response · Issue #26 · httpwg/http11bis () https://github.com/httpwg/http11bis/issues/26

[17] 201 のような意味で 204 を使うサーバーがあり、 Location: に作成された資源の URL を設定するようです。