ユーザーがログインしておらず、ログインが必要なページにアクセスしようとした場合、ログイン ページへのリダイレクトの正しい HTTP ステータス コードは何ですか?
W3C によって設定された 3xx 応答コード のいずれも要件に適合しないように思われるため、質問しています。
10.3.1 300 の複数の選択肢
要求されたリソースは、それぞれが独自の特定の場所を持つ一連の表現のいずれかに対応し、エージェント駆動のネゴシエーション情報 (セクション 12) が提供されるため、ユーザー (またはユーザーエージェント) は優先表現を選択し、その表現をリダイレクトできます。その場所にリクエストします。
HEAD 要求でない限り、応答には、ユーザーまたはユーザー エージェントが最も適切なものを選択できる、リソースの特性と場所のリストを含むエンティティを含める必要があります。エンティティ形式は、Content-Type ヘッダー フィールドで指定されたメディア タイプによって指定されます。フォーマットと機能に応じて
ユーザー エージェントは、最も適切な選択肢の選択を自動的に実行することができます (MAY)。ただし、この仕様では、そのような自動選択の基準は定義されていません。
サーバーが表現の好ましい選択肢を持っている場合、その表現の特定の URI を Location フィールドに含める必要があります。ユーザー エージェントは、自動リダイレクトに Location フィールドの値を使用してもよい[MAY]。特に明記しない限り、この応答はキャッシュ可能です。
10.3.2 301 恒久的に移動
要求されたリソースには新しい永続的な URI が割り当てられており、このリソースへの今後の参照では、返された URI のいずれかを使用する必要があります。リンク編集機能を持つクライアントは、可能であれば、Request-URI への参照をサーバーから返された 1 つ以上の新しい参照に自動的に再リンクする必要があります。特に明記しない限り、この応答はキャッシュ可能です。
新しい永続的な URI は、応答の Location フィールドで指定する必要があります。リクエスト メソッドが HEAD でない限り、レスポンスのエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートを含める必要があります。
GET または HEAD 以外のリクエストへの応答として 301 ステータス コードを受信した場合、ユーザーが確認できない限り、ユーザー エージェントはリクエストを自動的にリダイレクトしてはなりません。これにより、リクエストが発行された条件が変更される可能性があるためです。
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 は、応答の Location フィールドで指定する必要があります。リクエスト メソッドが HEAD でない限り、レスポンスのエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートを含める必要があります。
GET または HEAD 以外のリクエストに応答して 302 ステータス コードを受信した場合、ユーザーが確認できない限り、ユーザー エージェントはリクエストを自動的にリダイレクトしてはなりません。これにより、リクエストが発行された条件が変更される可能性があるためです。
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元のリクエスト メソッドに関係なく、Location フィールド値に対して GET を実行する 303 レスポンスでした。ステータス コード 303 および 307 は、クライアントに期待される反応の種類を明確に明らかにしたいサーバー用に追加されました。
10.3.4 303 その他を参照
リクエストへのレスポンスは別の URI で見つけることができ、そのリソースで GET メソッドを使用して取得する必要があります。このメソッドは主に、POST でアクティブ化されたスクリプトの出力がユーザー エージェントを選択したリソースにリダイレクトできるようにするために存在します。新しい URI は、最初に要求されたリソースの代替参照ではありません。303 応答はキャッシュしてはなりませんが、2 番目の (リダイレクトされた) 要求に対する応答はキャッシュ可能かもしれません。
応答の Location フィールドで別の URI を指定する必要があります (SHOULD)。リクエスト メソッドが 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 応答はメッセージ本文を含んではならないため、常にヘッダー フィールドの後の最初の空行で終了します。
応答には、次のヘッダー フィールドを含める必要があります。
- Date, unless its omission is required by section 14.18.1 If a時計のないオリジンサーバーはこれらのルールに従い、プロキシとクライアントは独自の日付を追加せずに受信した応答に追加します ([RFC 2068]、セクション 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 で弱いバリデータが使用された場合)、応答に他のエンティティ ヘッダーを含めてはなりません。これにより、キャッシュされたエンティティ本体と更新されたヘッダーの間の不一致が防止されます。
304 応答がエンティティが現在キャッシュされていないことを示している場合、キャッシュは応答を無視し、条件なしで要求を繰り返さなければなりません (MUST)。
キャッシュが受信した 304 応答を使用してキャッシュ エントリを更新する場合、キャッシュはエントリを更新して、応答で指定された新しいフィールド値を反映する必要があります。
10.3.6 305 プロキシを使用
要求されたリソースには、Location フィールドで指定されたプロキシを介してアクセスする必要があります。Location フィールドは、プロキシの URI を示します。受信者は、プロキシ経由でこの 1 つの要求を繰り返すことが期待されます。305 応答は、オリジン サーバーによってのみ生成されなければなりません。
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 は、応答の Location フィールドで指定する必要があります。HTTP/1.1 より前の多くのユーザー エージェントは 307 ステータスを理解していないため、リクエスト メソッドが HEAD でない限り、レスポンスのエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト メモを含める必要があります。したがって、メモには、ユーザーが新しい URI で元の要求を繰り返すために必要な情報を含める必要があります。
GET または HEAD 以外のリクエストに応答して 307 ステータス コードを受信した場合、ユーザーが確認できない限り、ユーザー エージェントはリクエストを自動的にリダイレクトしてはなりません。これにより、リクエストが発行された条件が変更される可能性があるためです。
正しい答えが見つかるまで、今のところ 302 を使用しています。
更新と結論:
HTTP 302 は、クライアント/ブラウザーとの互換性が最も優れていることが知られているため、より優れています。