3
ログインページにリダイレクトするときの正しいHTTPステータスコードは何ですか?
ユーザーがログインしておらず、ログインが必要なページにアクセスしようとすると、ログインページにリダイレクトするための正しい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 …