[311] 302 (Found) は、リダイレクトを表す状態符号です。 リダイレクトの状態符号はいくつかありますが、 302 が最も汎用的で、最も広く用いられています。

[312] 多くのプログラミング言語のライブラリーやHTTP鯖などでは、 リダイレクトの状態符号を明示しない場合、 302 が既定値として使われることが多いようです。

仕様書

意味

[313] 302 は、対象資源が一時的に異なる URL にあることを示します。リダイレクトはまた変わるかもしれませんから、 クライアントは以後の要求でもまた同じ実効要求URLを使い続けるべきought toです。 >>309

[314] ここでいう「一時的」とは「永続的」なリダイレクトを表す 301 のような状態符号との対比です。 301 の時はクライアントは新しい URL を以後かわりに使うべきとされています。

[6] 302 は、HTTPリダイレクトの最も一般的な状態符号です。 「リダイレクトする」ということ以上の特別な意味は持っていないと解釈するのが一般的です。

[7] 他により適切なリダイレクトの意味を表す状態符号がない場合や、 特に注意して使い分ける必然性または意思がない場合に使われます。

[3] 場合によっては 303 を使うべきであるとの主張もたまに見かけますが、 主として宗教的な理由による主張に過ぎないようです。積極的に 303 に変更するべき理由は見当たりません。

HTTPリダイレクトの項も参照。

[5] 302 はいつかリダイレクトを取りやめてかつてそこにあったコンテンツを表示するように戻すことを暗示していると主張する人もいますが、 根拠はありません。

[9] 301 は恒久的な移転で、もう旧 URL は使うべきではない、 という意思を示したいときに使います。 そのような意図がなく、 元の URL を使い続けてほしいときや、 元の URL を使ってもいいが新しい URL を使ってもどちらでもいいようなとき、 あるいはどう扱われるべきか態度を決めかねるようなときには、 302 を使うことができます。

[10] リダイレクトの状態符号を一々個別に指定する手段を提供しないようなソフトウェアの開発者は、 最も「汎用的」なリダイレクトである 302 を使うのが妥当です。

構文

[315] 鯖は、別の URL を含む Location: ヘッダーを生成するべきです >>309。

[12] なぜか必須でなく推奨に留まっていますが、 302 なのに Location: を指定しない応答を返すべき状況があるとは思えません。

[317] payload は通常は別の URL (群) へのハイパーリンクが含まれる短いハイパーテキストメモを含みます >>309。

[13] 「通常」となっていて要件とはされていないのですが、 一般的な慣習として、 HTML でリダイレクト先へのリンクを書きます。 といってもリダイレクトに対応しないクライアントは (意図的なものを除けば) 基本的に存在しないですし、 この HTML が表示されることはまずあり得ないので、 あってもなくても構わないのですが。 (実際省略されることも、ないでもありません。) リンクを1つ書くくらいサーバーソフトウェア開発者にとって大した労力ではないですし、 転送量も誤差のようなものなので、よほどの理由がない限りは前例に倣っておくのでよさそうです。[11] どちらも「別の」 URL と断られていますが、原理的には同じ URL を指定することもできますし、「別の」 URL が更にリダイレクトで、 巡り巡って元の URL に戻ってくることもあり得ます。 リダイレクトループと呼ばれる状態です。 こうした状態の処理は fetch や navigate で決まっています (がそれに従わないクライアントもあるかもしれず、 障害を起こしかねないので、要注意です)。

文脈

[8] 濫用例: Deep Packet Inspection, captive portal

処理モデル

[316] 利用者エージェントは、Location: ヘッダーの値を自動的なリダイレクトに使って構いません >>309。

[318] 歴史的理由により、利用者エージェントは続きの要求で POST を GET に変更して構いません >>309。 Web互換性のためには、変更しなければなりません >>4。

[319] この動作が好ましくない時は 307 を使えます >>309。

歴史

[310] RFC 1945 (HTTP/1.0); RFC 2068 (HTTP/1.1) 10.3.3 302 Moved Temporarily; RFC 2616 (HTTP/1.1) 10.3.3 302 Found

The requested resource resides temporarily under a different {1945} URL {2068,2616} URI. Since the redirection {1945,2068} may {2616} might be altered on occasion, the client {1945} should {2068,2616} SHOULD continue to use the Request-URI for future requests. {2068,2616} This response is only cacheable if indicated by a Cache-Control or Expires header field.

要求された資源は一時的に異なる URI の元にあります。 この redirect は折に触れて変わるかもしれないので、クライアントは(訳注)要求に使った Request-URI を将来の要求でも使い続けるべきです。 この応答は Cache-Control 頭欄又は Expires 頭欄で示されている場合に限りキャッシュ可能です。

{2068} If the new URI is a location, its {1945} The URL {2616} The temporary URI {1945} must SHOULD be given by the Location field in the response. Unless {1945} it was a HEAD request the request method was HEAD, the {1945} Entity-Body entity of the response {1945} should SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

一時 URI は応答の Location 欄に与えるべきです。 要求 method が HEAD でない限り、 応答の実体は新しい URI (群) へのハイパーリンクが入った短いハイパーテキストの覚書を含むべきです。

If the 302 status code is received in response to a request {1945} using the POST method {2068,2616} other than GET or HEAD {errata} method that is known to be "safe", as defined in section 9.1.1, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

「安全」と分かっている method の要求に対する応答で 302 状態符号を受取った時は、 利用者エージェントは要求を確認なしに自動的に redirect しても構いません。それ以外の場合は、 利用者エージェントは利用者の確認を得ることなしに自動的に redirect してはなりません。そうしないと要求が発行された条件が変わってしまうかもしれません。

{1945,2068} Note: When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

注意 : 301 状態符号を受信して POST 要求を自動的に redirect するときに、誤って GET 要求に変えてしまう HTTP/1.0 利用者エージェントが存在します。

{2616} Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.

注意 : RFC 1945 及び RFC 2068 は、クライアントが redirect 要求で method を変更することを許さないと規定しています。 しかし、ほとんどの既存の利用者エージェントは 302 を 303 応答のように扱い、元の要求 method に関わらず Location 欄値を GET します。どの種の再動作をクライアントに期待するかを曖昧なく明らかにしたいサーバーのために、 状態符号 303 及び 307 が追加されました。

[308] HTTP - WHATWG Wiki ( ( 版)) http://wiki.whatwg.org/wiki/HTTP#Redirects