ユーザーがログインしておらず、ログインが必要なページにアクセスしようとすると、ログインページにリダイレクトするための正しいHTTPステータスコードは何ですか。
W3Cによって設定された3xx応答コードの いずれも要件に適合していないように思われるので、私は尋ねています。
10.3.1 300複数の選択肢
要求されたリソースは表現のセットのいずれか1つに対応し、それぞれに固有の場所があり、ユーザー（またはユーザーエージェント）が優先表現を選択してリダイレクトできるように、エージェント駆動の交渉情報（セクション12）が提供されていますその場所へのリクエスト。
HEADリクエストでない限り、レスポンスには、ユーザーまたはユーザーエージェントが最も適切なものを選択できるリソースの特性と場所のリストを含むエンティティが含まれる必要があります（SHOULD）。エンティティの形式は、Content- Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。形式と機能に応じて
ユーザーエージェントでは、最も適切な選択肢の選択が自動的に実行される場合があります。ただし、この仕様では、このような自動選択の標準を定義していません。
サーバーが適切な表現の選択肢を持っている場合、その表現の特定のURIをLocationフィールドに含める必要があります。ユーザーエージェントは、自動リダイレクトにLocationフィールドの値を使用できます。特に指定のない限り、この応答はキャッシュ可能です。
10.3.2 301を永続的に移動
リクエストされたリソースには新しい永続的なURIが割り当てられており、このリソースへの今後の参照では、返されたURIの1つを使用する必要があります。リンク編集機能を持つクライアントは、Request-URIへの参照を、可能であればサーバーから返される1つ以上の新しい参照に自動的に再リンクする必要があります。特に指定のない限り、この応答はキャッシュ可能です。
新しい永続URIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります（SHOULD）。
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を使用する必要があります（SHOULD）。この応答は、Cache-ControlまたはExpiresヘッダーフィールドで示されている場合にのみキャッシュ可能です。
一時URIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります（SHOULD）。
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 it303レスポンスで、元のリクエストメソッドに関係なく、Locationフィールドの値に対してGETを実行しました。ステータスコード303および307は、どのような反応がクライアントに期待されるかを明確にしたいサーバー用に追加されました。
10.3.4 303他を参照
リクエストへの応答は別のURIで見つけることができ、そのリソースでGETメソッドを使用して取得する必要があります。このメソッドは主に、POSTでアクティブ化されたスクリプトの出力がユーザーエージェントを選択したリソースにリダイレクトできるようにするために存在します。新しいURIは、最初に要求されたリソースの代替参照ではありません。303応答はキャッシュしてはなりません（MUST NOT）が、2番目の（リダイレクトされた）要求への応答はキャッシュ可能である可能性があります。
異なるURIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります（SHOULD）。
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リクエストを実行し、アクセスは許可されているが、ドキュメントが変更されていない場合、サーバーはこのステータスコードで応答する必要があります（SHOULD）。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が弱いバリデーターを使用した場合）、応答に他のエンティティヘッダーを含めてはなりません（MUST NOT）。これにより、キャッシュされたエンティティ本体と更新されたヘッダーの間の不整合が防止されます。
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を使用する必要があります（SHOULD）。この応答は、Cache-ControlまたはExpiresヘッダーフィールドで示されている場合にのみキャッシュ可能です。
一時URIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、多くのHTTP / 1.1以前のユーザーエージェントは307ステータスを理解しないため、レスポンスのエンティティには新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります（SHOULD）。したがって、メモには、ユーザーが新しいURIで元の要求を繰り返すために必要な情報が含まれている必要があります（SHOULD）。
GETまたはHEAD以外のリクエストへの応答として307ステータスコードを受信した場合、ユーザーエージェントは、ユーザーが確認できない限り、リクエストを自動的にリダイレクトしてはなりません。これは、リクエストが発行された条件を変更する可能性があるためです。
正しい答えが見つかるまで、今のところ302を使用しています。
更新と結論：
HTTP 302は、クライアント/ブラウザとの互換性が最も高いことが知られているため、より優れています。