現在、UI 要素を表示する Web ページと、フォームの送信を処理してから UI ページにリダイレクトする Web ページがあります。PHP の header() 関数を使用してこれを行います。
header("Location: /other_page.php");
これにより、302 Found 応答が送信されます。HTTP 1.1 仕様によると、302 は「要求されたリソースが別の URI に一時的に存在する」場合です。【HTTP1.1仕様】
機能的にはこれで問題ありませんが、私たちが行っていることに対する適切なステータス コードではないようです。ここでは 303 ("See Other") が適切なステータスのように見えるので、使用しない理由があるかどうか疑問に思っています。Location: フィールドだけでなく、そのステータス行を指定する必要があるため、header() の使用をより明確にする必要があります。考え？
どちらも使用できますが、redirect-after-post に使用する適切なステータスコードは 303 です。
混乱には歴史的な説明があります。元々、302 は、ブラウザがリダイレクトされたリクエストのメソッドを変更してはならないことを指定していました。これにより、ブラウザに GET リクエストを発行させたいリダイレクト後のポストには不向きです。ただし、すべてのブラウザーは仕様を誤解しているようで、常に GET 要求を発行します。あいまいさを解消するために、HTTP/1.1 では 303 と 307 という 2 つの新しいコードを指定しました。303 は本質的に 302 の事実上の解釈を指定し、307 は 302 の元の仕様を指定します。したがって、実際には 302 と 303 は交換可能であり、理論 302 と 307 です。
HTTP/1.0 エージェントは 303 を理解できない可能性があるため、互換性を本当に気にする場合は、303 よりも 302 の方が安全です。303 を使用することをお勧めします。これが最も正しい方法です。
余談ですが; Locationフィールドは完全な URL である必要があります。実際には問題ではありません - ブラウザーは寛大です - しかし、仕様を気にするのであれば、それは適切なことです。
私はそれを自分で使用したことはありません...あなたのリンクにあるように：
注: 多くの HTTP/1.1 以前のユーザー エージェントは 303 ステータスを理解していません。このようなクライアントとの相互運用性が懸念される場合は、代わりに 302 ステータス コードを使用できます。これは、ほとんどのユーザー エージェントが 303 についてここで説明されているように 302 応答に反応するためです。
これは、私が 302 に固執する十分な理由のように思えます。
FYI header()は、ステータス コードを設定できる追加のパラメータを受け取ります。
header('Location: /foo.php', true, 303);
RoBorg の回答をさらに詳しく説明すると、多くのブラウザーは、非常に多くの HTTP 応答コードのうち、ほんの一握りしか理解していません。
補足: 検索エンジンの配置について少しでも心配している場合、302 は (おそらく) 問題を引き起こす可能性があります。