304

状態符号 304 (HTTP)

[18] 304 (Not Modified) は、 If-Modified-Since: ヘッダーで指定された時刻より後に対象資源が変更されていないことを示す状態符号です。

仕様書

意味

[8] 304 は、条件付き要求である GETHEAD要求を受信した際に、条件がでなかったなら 200 応答を送信していたであろうことを示す状態符号です >>7

[9] これはすなわち、クライアントが既に対象資源妥当表現を持っているため、 再度あえて転送する必要はなく、従ってクライアントが保持している表現200 応答payload だったかのようにリダイレクトするものです。 >>7

[10] これは一般的な意味の HTTPリダイレクトとは異なりますが、 HTTP 仕様上はクライアントの保持するキャッシュへの 「リダイレクト」に分類されています。

構文

[11] 304 応答生成するは、 200 応答だったなら送られるであろう次のヘッダーを同様に生成しなければなりません >>7

[17] 200 の時送らないものは、送る必要はありません。
[22] 206 でも同様の規定があります。

[12] 送信者は、 >>11 以外の表現メタデータキャッシュの更新の案内のためのものを除き、 生成するべきではありません >>7

[13] 例えば Last-Modified:ETag: がない場合に有用かもしれません >>7

[14] ... というような曖昧な規定よりも、適切なもの、不適切なもののリストを仕様書に含めていただけるた方が有用だと思うのですが... 他に該当しそうなものは Pragma: でしょうか。
[19] If-Modified-Since: に対する応答として 304 を返す場合について、以前にキャッシュされた応答を識別したり、 更新したりするのに有用なメタデータのみを含めるべき >>6 との規定がありますが、これらヘッダーに関する規定をより曖昧に言い直しただけに過ぎないと推測されます。 (なぜわざわざ曖昧に繰り返す必要があるのか謎ですが、RFC としては一般的な品質なので、 一々気にするだけ無駄でしょう。)

[16] TCN:透過的折衝可能資源304 応答に含めても構いません >>15

[20] これらのヘッダーについての情報は、 >>21JSON ファイルの 304_representation_metadata に含まれています。

[306] 304 応答は、メッセージ本体を持ちません >>305, >>7

文脈

[4] If-None-Match: の条件を満たさない場合で要求メソッドGETHEAD の場合には、 304 応答を返すことができます >>3

[5] If-Modified-Since: の条件を満たさない場合には、 304 応答を返すことができます >>6

処理モデル

[23] キャッシュの更新処理については、条件付き要求を参照。

歴史

[307] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified {1945} since the date and time specified in the If-Modified-Since field, the server {1945} must {2068} SHOULD respond with this status code {1945} and not send an Entity-Body to the client. {2068,2616} The 304 response MUST NOT contain a message-body, {2616} and thus is always terminated by the first empty line after the header fields. {1945} Header fields contained in the response should only include information which is relevant to cache managers or which may have changed independently of the entity's Last-Modified date. Examples of relevant header fields include: Date, Server, and Expires. A cache should update its cached entity to reflect any new field values given in the 304 response.

クライアントが条件付き GET 要求を行い、接続は認められたものの、 文書はIf-Modified-Since 欄に指定されて日付・時刻から修正されていないなら、 サーバーはこの状態符号で応答してはならず、クライアントに Entity-Body を送信してはなりません。するべきです。304 応答は message-body を含んでいてはならりませんで、従って頭欄の後の最初の空行で常に終端します応答中に含まれる頭欄はキャッシュ管理器に関係する情報又は実体の Last-Modified 日付に独立して変わったかもしれない情報のみを含むべきです。関係する頭欄の例 : Date, Server, Expires。キャッシュは、キャッシュした実体が 304 応答で与えられた新しい欄値を反映するように更新するべきです。

{2068,2616} The response MUST include the following header fields:

  • Date, unless its omission is required by section 14.18.1

応答は次の頭欄を含まなければなりません:

  • Date 省略が義務付けられている場合を除く

{2616} If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

時計のない起源サーバーはこれらの規則に従い、 串及びクライアントが自身の DateDate なしで受信した応答に付け加えれば、 キャッシュは正しく処理されます。

  • ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
  • Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

条件付き GET強いキャッシュ検証を使っているなら、 応答は他の実体頭欄を含むべきではありません。 そうでなければ、 (つまり条件付き GET が弱い検証を使っているなら、) 応答は他の実体頭欄を含んではなりません。 これによってキャッシュされている実体本体と更新された頭の不一致を防ぐことができます。

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

304 応答が実体は現在キャッシュされていないことを示すなら、 その時はキャッシュは応答を捨てて条件付きでない要求を繰り返さなければなりません

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

キャッシュが受信した 304 応答を使ってキャッシュ項目を更新するなら、 キャッシュは応答中に与えられた新しい欄値を反映して実体を更新しなければなりません

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

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

メモ

[1] この応答符号、明らかに意味が他の 3xx と違いますよねえ。。。

[2] XMLHttpRequeststatusCode304になることがよくありますが、それを考慮していない使用例が多過ぎのような気がします。。。 (名無しさん [sage] 2006-01-01 05:59:22 +00:00)

[24] Close #141: fix 304 handling · whatwg/fetch@1a2f6b4 ( 版) <https://github.com/whatwg/fetch/commit/1a2f6b49d616cfd74536c1a8dbed8b5c1215d548>