POSTリクエスト後のリダイレクト

すべてのWeb開発者は、フォームのPOST送信後、ユーザーがページを更新するときにデータが再度送信されないようにリダイレクトすることをお勧めします。 基本的に、これは重要な操作です。フォームデータをデータベースに保存したり、支払いトランザクションに参加したりできるためです。 そして、データは複製されるだけでなく、余分なお金が償却されます。



しかし、それはお金についてではなく、正しいリダイレクトについてです...



POST要求をリダイレクトすると、ほとんどすべてのWebアプリケーションが302 Foundのステータスを返します。 たとえば、phpでは、次のようにリダイレクトが行われます：header（ 'Location：/ new / location'）;。 追加のパラメーターがない場合、または別のステータスが別に指定されていない限り、関数は正確に302 Foundを返します。



では、公式文書に目を向けましょう。 RFC 2616は次のように述べています：

GETまたはHEAD以外のリクエストに応答して302ステータスコードを受信した場合、ユーザーが確認できない限り、ユーザーエージェントは自動的にリクエストをリダイレクトしてはなりません。リクエストが発行された条件が変わる可能性があるためです。



GETまたはHEAD以外のリクエストに応じてステータス302を受信した場合、ユーザーエージェントは、ユーザーの確認が得られるまでリクエストを自動的にリダイレクトしてはなりません。リクエストの条件に違反する可能性があるためです。



同じメモで、これにもかかわらず、多くのユーザーエージェントはこのルールを無視し、302ステータスを303として解釈すると書かれています。しかし、303ステータスがまだ存在していなかったHTTP / 1.0以来、これはなくなりました。



つまり POSTリクエストをリダイレクトするには、このために特別に設計された303 See Otherステータスを使用する必要があります。 phpでは、たとえば、リダイレクトは次のようになります。header（ 'Location：/ new / location'、true、303）;



RFCでは、ステータスノート303に次のように記載されています。

HTTP / 1.1より前の多くのユーザーエージェントは、303ステータスを理解していません。 このようなクライアントとの相互運用性が懸念される場合は、代わりに302ステータスコードを使用できます。これは、ほとんどのユーザーエージェントが、303についてここで説明したように302応答に反応するためです。



多くのpre-HTTP / 1.1ユーザーエージェントは303ステータスを理解していません。 そのようなクライアントとの互換性が重要な場合は、代わりに302ステータスを使用できます。これらのエージェントのほとんどは302ステータスと303に応答するためです



そして、2つのオプションが判明しました：

1.引き続き302を使用します。

a。 仕様を尊重して警告を発するユーザーエージェントに遭遇する可能性があります。

b。 この動作は標準ではないため、通常は予測できない結果になる可能性があります。



2. 303を使用すると、古い顧客は彼らに何を求めているのか理解できません。



2番目のケースでは、クライアントから要求されたプロトコルバージョンを分析し、古いクライアントに対して302を発行できます。 応答本文に、新しいURLへのリンクを記述します。 その後、古いエージェントのユーザーは少なくともリンクをクリックできます。