302リダイレクトと307リダイレクトの違いは何ですか？

違いは何だ302 FOUNDと307 TEMPORARY REDIRECTHTTPレスポンスは？

W3仕様では、どちらも一時的なリダイレクトに使用されており、応答で明確に許可されていない限り、どちらもキャッシュできないことが示されているようです。

違いは、リダイレクトPOST、リクエスト、PUTおよびDELETEユーザーエージェントの動作に対するサーバーの期待（RFC 2616）に関するものです。

注：RFC 1945およびRFC 2068では、クライアントがリダイレクトされた要求のメソッドを変更できないように指定されています。ただし、既存のほとんどのユーザーエージェント実装では、302を303応答のように扱い、元のリクエストメソッドに関係なく、Locationフィールドの値に対してGETを実行します。ステータスコード303および307は、クライアントにどのような反応が期待されるかを明確にしたいサーバー用に追加されました。

また、30xリダイレクトコードに関するWikipediaの記事もご覧ください。

307が発生したのは、ユーザーエージェントが302応答を受信し、GET要求をLocation応答ヘッダーに送信するPOST要求を取得するために、事実上の動作として採用されたためです。

これは不正な動作です。303 のみがPOSTをGETに変える必要があります。元のPOSTリクエストが302を返した場合、ユーザーエージェントは、新しいURLをリクエストするときにPOSTメソッドを使用する必要があります（使用しないでください）。

307は、サーバーがユーザーエージェントに対して、Location応答ヘッダーをたどるときにメソッドの変更がクライアントによって行われるべきではないことを明確にすることを可能にするために導入されました。

動作中の良い例307 Internal Redirectは、Google Chromeが、厳密なトランスポートセキュリティが必要であると認識しているドメインへのHTTP呼び出しを検出した場合です。

ブラウザは、元の呼び出しと同じ方法を使用してシームレスにリダイレクトします。

• 301：永続的なリダイレクト：URLは古く、置き換える必要があります。ブラウザはこれをキャッシュします。
  使用例： URLをから/register-form.htmlに移動しましたsignup-form.html。
  RFC 7231に従い、メソッドはGETに変更されます。「歴史的な理由により、ユーザーエージェントは、後続のリクエストのためにリクエストメソッドをPOSTからGETに変更できます。」
• 302：一時的なリダイレクト。HTTP / 1.0クライアントにのみ使用します。このステータスコードはメソッドを変更するべきではありませんが、ブラウザはとにかくそれを変更しました。RFCによると、「HTTP / 1.1より前の多くのユーザーエージェントは、[303]を理解していません。このようなクライアントとの相互運用性が懸念される場合は、代わりに302ステータスコードを使用できます。 303のために。」もちろん、一部のクライアントは仕様に従ってそれを実装している可能性があるため、このような古いクライアントとの相互運用性が本当の懸念事項ではない場合、一貫した結果を得るためには303の方が適しています。
• 303：一時的なリダイレクト、メソッドをGETに変更。
  使用例：ブラウザがPOSTを/register.phpに送信した場合、ロード（GET）し/success.htmlます。
• 307：一時的なリダイレクト。リクエストを同じように繰り返します。
  使用例：ブラウザがにPOSTを送信した場合、/register.phpこれはにPOSTをやり直すように指示し/signup.phpます。
• 308：永続的なリダイレクト。リクエストを同じように繰り返します。307が303の「メソッド変更なし」の対応物である場合、この308ステータスは301の「メソッド変更なし」の対応物です。

RFC 7231（2014年から）は非常に読みやすく、過度に冗長ではありません。正確な回答を知りたい場合は、お読みください。他のいくつかの回答は1999年のRFC 2616を使用していますが、変更はありません。

RFC 7238は308ステータスを指定しています。これは実験的なものと見なされていますが、2016年にはすでにすべての主要なブラウザでサポートされていました。

302の期待：リダイレクトはNEW_URLで同じリクエストメソッドPOSTを使用します

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL

302、303の実績：NEW_URLでPOSTからGETに変更リクエストメソッドをリダイレクト

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)

307の実績：リダイレクトはNEW_URLで同じリクエストメソッドPOSTを使用します

CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL

302はサーバーによって生成される一時的なリダイレクトで、307はブラウザーによって生成される内部リダイレクト応答です。内部リダイレクトとは、リダイレクトがブラウザーによって内部的に自動的に行われることを意味します。基本的に、ブラウザーはgetリクエストで入力されたURLをhttpからhttpsに変更してからリクエストを行うため、インターネットへの安全でない接続のリクエストは行われません。ブラウザがURLをhttpsに変更するかどうかは、ブラウザにプリインストールされているhstsプリロードリストに依存します。chrome：// net-internals /＃hstsにある独自のブラウザーのhstsプリロードリストにドメインを入力することにより、httpsをサポートするサイトをリストに追加することもできます。所有者は、さらに1つのWebサイトドメインを追加できますhttps://hstspreload.org/のフォームに入力してリストをプリロードする特に自分でもできると言っても、すべてのユーザーのブラウザーにプリインストールされています。

例を挙げて説明し ます。httpsのみをサポート
するhttp://www.pentesteracademy.comに getリクエストを行いましたが、サイトの所有者がドメインに登録していないため、ブラウザのhstsプリロードリストにそのドメインがありません。プリインストールされたhstsプリロードリストが付属しています。 安全でないバージョンのサイトに対するGETリクエストは、安全なバージョンにリダイレクトされます（上の画像の応答で、その場所の名前付きhttpヘッダーを参照してください）。 次に、chrome：// net-internals /＃hstsのhstsドメインの追加フォームにドメインを追加して、自分のブラウザーのプリロードリストにサイトを追加します。これにより、Chromeブラウザーの個人用プリロードリストが変更されます。 STSオプションがあります。 hstsプリロードリストに追加した後、同じWebサイトの要求と応答を見てみましょう。




応答ヘッダーの内部リダイレクト307を確認できます。実際には、この応答はサーバーではなくブラウザーによって生成されます。
また、HSTSプリロードリストは、302リダイレクトがミット攻撃を受けやすいため、ユーザーが安全でないバージョンのサイトに到達するのを防ぐのに役立ちます。
リダイレクトについて理解を深めるのに少し役立ったと思います。

もともとあった 302

| Response               | What browsers should do   |
|------------------------|---------------------------|
| 302 Found              | Redo request with new url |

アイデアは次のとおりです。

• GETある場所でを行っていた場合はGET、新しいURLにやり直します
• POSTある場所でを行っていた場合はPOST、新しいURLにやり直します
• PUTある場所でを行っていた場合はPUT、新しいURLにやり直します
• DELETEある場所でを行っていた場合はDELETE、新しいURLにやり直します
• 等

残念ながら、すべてのブラウザがそれを間違っていました。取得する場合302、彼らはいつもに切り替えてしまうGETというと、要求を再試行するよりも、新しいURLに同じ動詞（例えば、POST）：

• モザイクはそれを間違った
• NetscapeはMosaicのバグをコピーしました。彼らはそれを間違った
• Internet ExplorerはNetscapeのバグをコピーしました。彼らはそれを間違った

デファクトになりました間違いた。

すべてのブラウザで302問題が発生しました。だから、303および307作成されました。

| レスポンス| ブラウザがすべきこと| ブラウザが実際に行うこと| | ------------------------ | ------------------------ --- | --------------------------- | | 302見つかりました| 新しいURLでリクエストをやり直す| 新しいURLで取得| | 303他を見る| 新しいURLで取得| 新しいURLで取得| | 307一時的なリダイレクト| 新しいURLでリクエストをやり直す| 新しいURLでリクエストをやり直す|

グラフ形式

5種類のリダイレクト：

╔═══════════╤════════════════════════════════════════════════╗
║           │                Switch to GET?                  ║
║ Temporary │          No            │         Yes           ║
╠═══════════╪════════════════════════╪═══════════════════════╣
║ No        │ 308 Permanent Redirect │ 301 Moved Permanently ║
╟───────────┼────────────────────────┼───────────────────────╢
║ Yes       │ 307 Temporary Redirect │ 303 See Other         ║
║           │ 302 Found (intended)   │ 302 Found (actual)    ║
╚═══════════╧════════════════════════╧═══════════════════════╝

または：

| Response                 | Switch to get? | Temporary? |
|--------------------------|----------------|------------|
| 301 Moved Permanently    | No             | No         |
| 302 Found (intended)     | No             | Yes        |
| 302 Found (actual)       | Yes            | Yes        |
| 303 See Other            | Yes            | Yes        |
| 307 Temporary Redirect   | No             | Yes        |
| 308 Permanent Redirect   | No             | No         |

また、サーバー管理者にとって、307リダイレクトを使用する場合、ブラウザがユーザーにプロンプ​​トを表示する場合があることに注意することが重要な場合があります。

たとえば、*、FirefoxとOperaはリダイレクトの許可をユーザーに要求しますが、Chrome、IE、Safariは透過的にリダイレクトを行います。

_{* Bulletproof SSLおよびTLSごと（192ページ）。}

ユースケースによっては、攻撃者が307リダイレクトを悪用して、被害者の資格情報を入手する場合があります。

詳細については、OAuth 2.0の包括的な正式なセキュリティ分析のセクション3.1をご覧ください。。

上記の論文の著者は、次のことを提案しています。

修正。OAuth標準の現在の表現とは異なり、リダイレクトの正確な方法は実装の詳細ではありませんが、OAuthのセキュリティにとって不可欠です。HTTP標準（RFC 7231）では、HTTP POSTリクエストの本文を削除するために明確に定義されているのは303リダイレクトのみです。最も一般的に使用される302を含む他のすべてのHTTPリダイレクトステータスコードは、POSTリクエストとフォームデータを保持するオプションをブラウザに残します。実際には、ブラウザは通常、GETリクエストに書き直し、307リダイレクトを除いてフォームデータをドロップします。したがって、OAuth標準では、この問題を解決するために、上記の手順で303リダイレクトが必要です。