[解決済み] ログインページにリダイレクトする際の正しいHTTPステータスコードは何ですか？

質問

ユーザーがログインしていない状態で、ログインが必要なページにアクセスしようとしたとき、ログインページへのリダイレクトのための正しいHTTPステータスコードは何でしょうか？

この質問をしているのは、どの W3Cが定めた3xxレスポンスコード と思われる という要件に合致する。

10.3.1 300 複数選択可能

要求されたリソースは、以下のものに対応する。 一連の表現のうちのいずれか1つ。 は、それぞれ特定の場所を持つ。 とエージェント主導のネゴシエーション 情報(12項)を提供しています。 ユーザー（またはユーザー エージェントが選択することができます。 表現とそのリダイレクト リクエストをその場所に送る。

HEADリクエストでない限り を含むべきである（SHOULD）。 リソースのリストを含む の特性および場所 ユーザーまたはユーザーエージェントが が最も適切なものを選択する。その際 エンティティの形式は で指定されるメディアタイプ。 ヘッダフィールドがあります。によって のフォーマットと

ユーザーエージェントは 適切な選択肢を実行してもよい。 を自動生成する。しかし、この 仕様は、いかなる定義も行わない。 このような自動選択のための規格

サーバーが優先的に選択するものがある場合 を含めるべきです。 そのURIの具体的な の表現をLocationフィールドに記述する。 ユーザーエージェントはLocationフィールドを使用してもよい の値を自動リダイレクションのために使用する。この レスポンスは、指定されない限り、キャッシュ可能です。 である。

10.3.2 301 恒久的に移動された

要求されたリソースは は新しいパーマネントURIを割り当てられ、すべての 今後、このリソースへの参照は 返されたURIのいずれかを使用すべきです(SHOULD)。 リンク編集機能を持つクライアント を自動的に再リンクする必要があります。 への参照は、そのRequest-URIの1つの またはそれ以上の新しい参照が返される。 可能であれば、サーバによって この レスポンスは、指定されない限りキャッシュ可能です。 を使用する。

新しいパーマネントURIを与えるべきである(SHOULD)。 は、レスポンスのLocationフィールドで指定する。 リクエストメソッドがHEADでなければ レスポンスのエンティティは を含む短いハイパーテキストノートが含まれています。 新しい URI へのハイパーリンク。

ステータスコード 301 を受信した場合 以外のリクエストに対する応答として、GET またはHEADの場合、ユーザーエージェントは 自動的にリダイレクトする が確認できない限り を変更する可能性があるからです。 リクエストの条件 を発行した。

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

10.3.3 302が見つかりました

要求されたリソースは を一時的に別のURIで使用します。 リダイレクションは変更される可能性があるため を使用することをお勧めします。 は、引き続きそのRequest-URIを使用します。 今後のリクエストに対応します。この応答は によって示される場合、キャッシュ可能です。 Cache-Control または Expires ヘッダーフィールド。

一時的なURIは、次のように指定されるべきです（SHOULD）。 応答中のLocationフィールド リクエストメソッドがHEADでない限り レスポンスのエンティティは を含む短いハイパーテキストノートが含まれています。 新しい URI へのハイパーリンク。

302ステータスコードを受信した場合 以外のリクエストに応答して、GET またはHEADを使用する場合、ユーザーエージェントは 自動的にリダイレクトする が確認できない限り を変更する可能性があるからです。 リクエストの条件 を発行した。

  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

は303 レスポンスで、Location フィールドの値に対して GET を実行します。 を、元のリクエストメソッドから削除します。ステータスコード303と307は を明確にしたいサーバーのために追加されました。 のような反応をクライアントに期待します。

10.3.4 303 その他を見る

リクエストに対するレスポンスは は別のURIで見つかり、そのURIを使用すべきです（SHOULD）。 のGETメソッドで取得することができます。 そのリソースの このメソッドは の出力を可能にするためです。 POSTで起動されたスクリプトをリダイレクトするために ユーザーエージェントを選択したリソースに このとき 新しいURIは代替参照ではありません。 は、元々要求されたリソースのためのものである。 303応答はキャッシュされてはならない[MUST NOT]。 しかし、2番目の (リダイレクトされた) リクエストは はキャッシュ可能である。

異なるURIは、次のように指定されるべきです(SHOULD)。 は、レスポンスのLocationフィールドになります。 リクエストメソッドがHEADでない限り レスポンスのエンティティは を含む短いハイパーテキストノートが含まれています。 新しい URI へのハイパーリンク。

  Note: Many pre-HTTP/1.1 user agents do not understand the 303
  status. When interoperability with such clients is a concern, the
  302 status code may be used instead, since most user agents react
  to a 302 response as described here for 303.

10.3.5 304 修正されていない

クライアントが 条件付きGETリクエストでアクセスが許可されると が許可されているが、ドキュメントが が変更された場合、サーバーは次のように応答すべきです。 は、このステータスコードで示されます。このとき、304 を含んではならない。 メッセージボディを持つため、常に 最初の空行で終了する ヘッダーフィールドの後に

応答は以下のものを含まなければならない(MUST)。 以下のヘッダーフィールドがあります。

  - Date, unless its omission is required by section 14.18.1 If a

クロックレスオリジンサーバーは、これらの ルールがあり、プロキシやクライアントは を使用した場合、そのレスポンスに がない状態で受け取った（すでに RFC2068]のセクションで規定されている。 14.19)、キャッシュは正しく動作する。

  - 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

セクション13.3.3)で説明したように、レスポンスは 他のエンティティヘッダを含んではならない。 そうでない場合（つまり、条件付きGET が弱いバリデータを使用した場合)、レスポンス 他のエンティティヘッダを含んではならない(MUST NOT)。 これは キャッシュされたエンティティボディと更新された ヘッダを作成します。

304 レスポンスがエンティティを示す場合 現在キャッシュされていない場合、キャッシュは その応答は無視し、繰り返し行わなければならない(MUST)。 を、条件なしでリクエストする。

キャッシュが受信した304 レスポンスを使用してキャッシュエントリを更新する場合、その を反映させるためにエントリーを更新しなければならない（MUST）。 で指定された新しいフィールド値 レスポンスに対応する。

10.3.6 305 プロキシを使用する

リクエストされたリソースは で指定されたプロキシを経由してアクセスします。 は、Location フィールドを指定する。Locationフィールドは はプロキシのURIを与える。プロキシは 受信者はこの プロキシを経由した単一のリクエストです。305 のみで生成されなければならない（MUST）。 オリジンサーバ

  Note: RFC 2068 was not clear that 305 was intended to redirect a
  single request, and to be generated by origin servers only.  Not
  observing these limitations has significant security consequences.

10.3.7 306 (未使用)

ステータスコード306は、以前 仕様の前のバージョン。 は使用されなくなったので、このコードは を予約した。

10.3.8 307 一時的なリダイレクト

要求されたリソースは を一時的に別の URI で使用する。 リダイレクションは変更されてもよいので を使用することをお勧めします。 は、引き続きそのRequest-URIを使用します。 今後のリクエストに対応します。この応答は によって示される場合、キャッシュ可能です。 Cache-Control または Expires ヘッダーフィールド。

一時的なURIは、次のように指定されるべきです（SHOULD）。 応答中のLocationフィールド リクエストメソッドがHEADでない限り レスポンスのエンティティは を含む短いハイパーテキストノートが含まれています。 新しい URI へのハイパーリンク。 HTTP/1.1以前のユーザーエージェントは、その多くが は307ステータスを理解します。したがって を含むべきである。 ユーザが必要な情報 新しい URIを使用する。

ステータスコード307を受信した場合 以外のリクエストに対する応答として、GET またはHEADを使用する場合、ユーザーエージェントは、MUST NOT 自動的にリクエストをリダイレクトする が確認できない限り を変更する可能性があるからです。 リクエストの条件 を発行した。

を見つけるまで、とりあえず302を使っています。 その が正解です。

更新＆amp;結論。

HTTP 302は、クライアントやブラウザとの互換性が最も高いことが知られているため、より優れています。

解決方法は？

というと <ストライク 303 その他を見る 302 見つかりました。

要求されたリソースは一時的に別のURIで存在します。リダイレクトは は変更されることがあります。 クライアントは、今後のリクエストには引き続きそのRequest-URIを使用す るべきである[SHOULD]。この応答は、Cache-ControlまたはExpiresヘッダーフィールドで示される場合に のみ、キャッシュ可能である。

は、ログインページに最も近いと私は考えています。私は最初 303 see other ということです。いろいろ考えた結果、私は 302 Found はより適切で、要求されたリソース は が見つかり、アクセスできるようになるまでに別のページが必要なだけです。レスポンスはデフォルトでキャッシュされませんが、これも問題ありません。