HTTPリダイレクトコードの違い

さまざまなHTTP 3XXリダイレクトコードの違いは明確ではありません。はい、私は仕様を読みましたが、ここでは標準と実際の実践との間にいくつかの矛盾があるようです。

301リダイレクトコードは明らかに十分なようだ：リソースが恒久的に別のURIに移動されました。この手段を、そして未来の要求はURIことを使用する必要があります。

また、307リダイレクトコードも明確に見えます。つまり、リダイレクトは一時的なものであり、今後のリクエストでは引き続き元のURIを使用する必要があります。

しかし、私は違いが間にあるものを言うことができない302と303、あるいはそれらのいずれかから、本当に異なっている理由301。302もともとは一時的なリダイレクト（のような307）を意図していたようですが、実際には、ほとんどのブラウザはのように処理していました303。しかし、a 303とaの違いは何301ですか？される301リダイレクトがあることを意味することになって、より恒久的な？

• 301：永続的なリダイレクト。このリソースに対する後続のリクエストを行うクライアントは、新しいURIを使用する必要があります。クライアントは、POST / PUT / DELETE要求のリダイレクトを自動的にたどってはなりません。
• 302：未定義の理由でリダイレクトします。このリソースに対する後続のリクエストを行うクライアントは、新しいURIを使用しないでください。クライアントは、POST / PUT / DELETE要求のリダイレクトを自動的にたどってはなりません。
• 303：未定義の理由でリダイレクトします。通常、「操作は完了しました。他の場所で続行してください。」このリソースに対する後続のリクエストを行うクライアントは、新しいURIを使用しないでください。クライアントは POST / PUT / DELETEリクエストのリダイレクトに従いますが、フォローアップリクエストにはGETを使用します。
• 307：一時的なリダイレクト。リソースは後でこの場所に戻る可能性があります。このリソースに対する後続のリクエストを行うクライアントは、古いURIを使用する必要があります。クライアントは、POST / PUT / DELETE要求のリダイレクトを自動的にたどってはなりません。

個人的には、選択肢があれば302を避けることをお勧めします。多くのクライアントは、302に遭遇したときに仕様に準拠していません。一時的なリダイレクトの場合は、非GETリクエストで必要な動作のタイプに応じて、303または307を使用する必要があります。POST / PUT / DELETEで別の動作が必要でない限り、307から303を優先してください。

303と307の違いは次のとおりです。

303：他を参照してください。リクエストは正しく受信されますが、結果はリダイレクトURLでGETを使用して取得する必要があります。

307：一時的なリダイレクト。リクエスト全体を新しいURLにリダイレクトする必要があります。投稿データは再投稿する必要があります。

302は307の動作を意図したものでしたが、ほとんどのブラウザーはそれを303の動作として実装したことに注意してください（どちらも当時は存在しませんでした）。したがって、これらの2つの新しいコードは302を置き換えるために導入されました。

301と303の違い：

301：ドキュメントが移動されました。今後のリクエストでは、新しいURLを使用する必要があります。このURLは廃止されました。

注：このコードには注意してください。ブラウザとプロキシは、非常に積極的なキャッシュを適用する傾向があるため、301で返信すると、誰かがそのURLに再度アクセスするまでに時間がかかる場合があります。

303：リクエストは正しく受信されました。すべてのPUT要求が処理されます。結果のドキュメントには、リダイレクトURLから取得することができます。今後のリクエストでは、元のURLに移動する必要があります。