ログインページにリダイレクトするときの正しい HTTP ステータス コードは何ですか? 質問する

ユーザーがログインしておらず、ログインが必要なページにアクセスしようとした場合、ログイン ページにリダイレクトするための正しい HTTP ステータス コードは何ですか?

私が質問しているのは、W3Cが定めた3xxレスポンスコード 思われる要件を満たすために:

10.3.1 300 複数選択

要求されたリソースは、それぞれ独自の特定の場所を持つ表現セットのいずれかに対応し、エージェント駆動型ネゴシエーション情報 (セクション 12) が提供されるため、ユーザー (またはユーザー エージェント) は好みの表現を選択し、その場所に要求をリダイレクトできます。

HEADリクエストでない限り、レスポンスには、ユーザーまたはユーザーエージェントが最も適切なものを選択できるリソース特性と場所のリストを含むエンティティを含める必要があります。エンティティのフォーマットは、Content-Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。

ユーザーエージェントでは、最も適切な選択肢の選択が自動的に実行される場合があります。ただし、この仕様では、このような自動選択の標準は定義されていません。

サーバーが優先する表現方法を選択した場合、その表現の特定の URI を Location フィールドに含める必要があります。ユーザー エージェントは、自動リダイレクトに Location フィールド値を使用できます。特に指定がない限り、この応答はキャッシュ可能です。

10.3.2 301 永久に移動

要求されたリソースには新しい永続的な URI が割り当てられており、このリソースへの今後の参照では、返された URI の 1 つを使用する必要があります。リンク編集機能を持つクライアントは、可能な場合は、Request-URI への参照を、サーバーから返された 1 つ以上の新しい参照に自動的に再リンクする必要があります。特に指定がない限り、この応答はキャッシュ可能です。

新しい永続的な URI は、応答の Location フィールドによって指定される必要があります。要求メソッドが HEAD でない限り、応答のエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートが含まれている必要があります。

GET または HEAD 以外のリクエストへの応答として 301 ステータス コードを受信した場合、リクエストが発行された条件が変わる可能性があるため、ユーザー エージェントは、ユーザーが確認しない限り、リクエストを自動的にリダイレクトしてはなりません (MUST NOT)。

  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

303 応答では、元のリクエスト方法に関係なく、Location フィールド値に対して GET が実行されます。ステータス コード 303 と 307 は、クライアントにどのような応答が期待されるかを明確にしたいサーバーのために追加されました。

10.3.4 303 その他を参照

リクエストへの応答は別の URI で見つかる可能性があり、そのリソースの GET メソッドを使用して取得する必要があります。このメソッドは主に、POST でアクティブ化されたスクリプトの出力がユーザー エージェントを選択したリソースにリダイレクトできるようにするために存在します。新しい URI は、最初にリクエストされたリソースの代替参照ではありません。303 応答はキャッシュしてはなりませんが、2 番目の (リダイレクトされた) リクエストへの応答はキャッシュできる可能性があります。

異なる URI は、応答の 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 応答にはメッセージ本文を含めることはできません。したがって、常にヘッダー フィールドの後の最初の空行で終了します。

応答には次のヘッダー フィールドが含まれている必要があります。

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

クロックレスオリジンサーバーがこれらのルールに従い、プロキシとクライアントが受信した応答に独自の Date を追加すると ([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 応答が現在キャッシュされていないエンティティを示している場合、キャッシュは応答を無視し、条件なしで要求を繰り返す必要があります。

キャッシュが受信した 304 応答を使用してキャッシュ エントリを更新する場合、キャッシュは応答で指定された新しいフィールド値を反映するようにエントリを更新する必要があります。

10.3.6 305 プロキシを使用する

要求されたリソースには、Location フィールドで指定されたプロキシを介してアクセスする必要があります。Location フィールドにはプロキシの URI が示されます。受信者は、プロキシ経由でこの単一の要求を繰り返す必要があります。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 フィールドで指定する必要があります。リクエスト メソッドが HEAD でない限り、多くの HTTP/1.1 以前のユーザー エージェントは 307 ステータスを理解しないため、応答のエンティティには、新しい URI へのハイパーリンクを含む短いハイパーテキスト ノートを含める必要があります。したがって、ノートには、ユーザーが新しい URI で元のリクエストを繰り返すために必要な情報を含める必要があります。

GET または HEAD 以外のリクエストへの応答として 307 ステータス コードが受信された場合、リクエストが発行された条件が変わる可能性があるため、ユーザー エージェントは、ユーザーが確認しない限り、リクエストを自動的にリダイレクトしてはなりません (MUST NOT)。