コンセプト

301 Moved Permanently 要求されたリソースは新しい場所に永久に移動されました。このリソースへの今後の参照では、この応答で返されたいくつかの URI の 1 つを使用する必要があります。可能であれば、リンク編集機能を持つクライアントは、要求されたアドレスをサーバーから返されたアドレスに自動的に変更する必要があります。特に指定がない限り、この応答もキャッシュ可能です。新しい永続的な URI は、応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。これが GET または HEAD リクエストではない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限りブラウザは自動リダイレクトを禁止します。注: HTTP/1.0 プロトコルを使用する一部のブラウザでは、送信した POST リクエストが 301 レスポンスを受け取ると、後続のリダイレクトリクエストは GET メソッドになります。

302 Found 要求されたリソースは、別の URI からの要求に一時的に応答するようになりました。このようなリダイレクトは一時的なものであるため、クライアントは今後も元のアドレスにリクエストを送信し続ける必要があります。この応答は、Cache-Control または Expires で指定されている場合にのみキャッシュ可能です。新しい一時 URI は、応答の Location フィールドで返される必要があります。これが HEAD リクエストでない限り、応答エンティティには新しい URI へのハイパーリンクと簡単な説明が含まれている必要があります。これが GET または HEAD リクエストではない場合、リクエストの条件がそれに応じて変更される可能性があるため、ユーザーが確認しない限りブラウザは自動リダイレクトを禁止します。注: RFC 1945 および RFC 2068 の仕様では、クライアントがリダイレクト時にリクエストメソッドを変更することを許可していませんが、多くの既存のブラウザは 302 レスポンスを 303 レスポンスと見なし、場所に関係なく、GET メソッドを使用して Location で指定された URI にアクセスします。元のリクエストのメソッド。ステータスコード 303 および 307 は、サーバーがクライアントからどのような応答を期待しているかを明確にするために追加されました。

これはウィキペディアから得た概念です。読んだ後でも、大まかなアイデアは得られます。 301 は、アクセスされたリソースが完全に削除されており、クライアントは新しい URI に従ってリダイレクトにアクセスする必要があることを意味します。302 は、アクセスされたリソースに場所 URI を使用して一時的にアクセスできるが、次回アクセスしたときに古いリソースがまだ存在していることを意味します。再度アクセスするときにリダイレクトする必要がない場合があります。

一般的なアプリケーションシナリオ

シナリオ 1: ドメイン名を変更する必要があり、古いドメイン名が必要なくなった場合、ユーザーが古いドメイン名にアクセスすると、301 を使用して新しいドメイン名にリダイレクトされます。実際、これは、含まれるドメイン名に新しいドメイン名を含める必要があることも検索エンジンに伝えます。
シナリオ 2: ログイン後に指定されたページにリダイレクトします。このシナリオは、ログインが成功し、特定のシステムページにジャンプする場合によく見られます。
シナリオ 3 5 秒後に注文詳細ページに戻るなど、ページを自動的に更新する必要がある場合があります。
シナリオ 4 システムをアップグレードしたり、特定の機能を切り替えたりするときに、アドレスを一時的に変更する必要がある場合があります。
シナリオ 5: Weibo などには短いドメイン名が使用されており、ユーザーは閲覧後に実際のアドレスにリダイレクトされる必要があります。

コードデモ

リーリー

ユーザーがアクセスすると、ブラウザは http://127.0.0.1/login.htm にリダイレクトされます

301と302を選ぶ際の注意点

302 リダイレクトと URL ハイジャック (URL ハイジャック) URL A から URL B への 302 リダイレクトを行う場合、ホストサーバーの暗黙の意味は、URL A がいつでも考えを変え、独自のコンテンツを再表示したり、他の場所にリダイレクトしたりする可能性があるということです。。ほとんどの場合、302 リダイレクトを受信した場合、ほとんどの検索エンジンはターゲット URL (URL B) をクロールするだけで済みます。 302 リダイレクトが発生したときに検索エンジンがターゲット URL B を 100% クロールする場合、URL ハイジャックを心配する必要はありません。問題は、検索エンジン、特に Google が常にターゲット URL をクロールするとは限らないことです。たとえば、URL A は非常に短い場合がありますが、URL B への 302 リダイレクトが行われ、URL B は長くて乱雑な URL になり、疑問符などのパラメータが含まれる場合もあります。当然のことながら、URL A の方がユーザーフレンドリーですが、URL B は醜く、ユーザーフレンドリーではありません。現時点では、Google は URL A を表示する可能性が高くなります。検索エンジンのランキングアルゴリズムは単なるプログラムであり人間ではないため、302 リダイレクトに遭遇した場合、人間のようにどの URL がより適切であるかを正確に判断できず、URL ハイジャックの可能性が生じます。つまり、悪意のある人が自分の Web サイト A からあなたの Web サイト B に 302 リダイレクトを行います。何らかの理由で、Google 検索結果には引き続き Web サイト A が表示されますが、使用される Web ページのコンテンツはあなたの Web サイト B のコンテンツです。この状況は Web サイトの URL ハイジャックと呼ばれます。あなたが一生懸命書いた内容が他人に盗まれてしまいました。 302 リダイレクトによる URL ハイジャックは以前から存在していました。しかし今のところ、これより良い解決策はないようです。 302 リダイレクトの問題は、進行中の Google Big Daddy データセンター変換中に対処すべきターゲットの 1 つでもあります。一部の検索結果を見る限り、URLハイジャック現象は改善されてきていますが、完全に解決されたわけではありません。

一般的な意味は、検索エンジンのランキングに影響を与えるということであり、302 リダイレクトは、複数のドメイン名を使用して同じ Web サイトを指すものとして検索エンジンに誤解されやすく、Web サイトがブロックされる可能性があります。

つまり、本当に 302 を使用した一時的なリダイレクトでない限り、それ以外の場合は 301 を使用するのが最善です