実はGET(とHEAD)でリクエストされた時の動作は変わりません。 違いはPOST(やPUT/DELETE/OPTIONS)でリクエストされた時の動作です。
**"307 Temporary Redirect(一時的リダイレクト)"**は最初のURLでは実際の処理は行わず、リダイレクト先に改めてリクエストを出し直して欲しい時に使います。 したがって、最初のリクエストがPOSTであれば、 ブラウザはリダイレクト先にもPOSTを使います。 "301 Moved Permanently(恒久的リダイレクト)"の「一時的」版であると思えばよいでしょう。
**"303 See Other(他を参照せよ)"**はPOSTによる処理を最初のURLで実際に行ったが、レスポンスはリダイレクト先からGETで取得して欲しい時に使います。 したがって、最初のリクエストがPOST であってもブラウザはリダイレクト先にはGETを使います。
**302 Found(発見した)**は過去の遺物となったコードです。新しく作るWEBサイトでは使うべきではないでしょう。
HTTP 1.0の規格では、302に対してブラウザは307相当の動作（リダイレクト先にも同じ動詞を使う）ことになっていました。 しかし、多くのブラウザは303相当の動作（リダイレクト先にはGET）をしていました。 一方で、この規格外の仕様を前提にしたWEBサイトも存在しており、今さらブラウザの仕様を訂正することもできませんでした。
そのため、HTTP 1.1では303（実際のブラウザの仕様）と307（302の本来の動作）が定義されました。
以下、日本語訳から抜粋します。各ステータスコードで共通する部分と、HTTP 1.1以前のブラウザに関する注意は省略しています。
リクエストされたリソースは、一時的に別の URI に属している。(中略)
注意: RFC 1945 や RFC 2068 では、クライアントはリダイレクトするリクエストのメソッドを変えてはならないと明確に述べられている。 しかしながら、多くの既存ユーザエージェントは 302 レスポンスをまるで 303 レスポンスのようにみなし、元々のリクエストメソッドにかかわらず Location フィールド値へと GET を行う。ステータスコード 303 と 307は、クライアントが期待する反応の種類を明確にしたいというサーバのために加えられた。
リクエストに対するレスポンスは別の URI の元から発見でき、このリソース を GET メソッドを使用して回収す べきである。このメソッドは、主に POST によって活性化される {POST-activated} スクリプトの出力が選択され たリソースへユーザエージェントをリダイレクトできるようにするために存 在する。新しい URI は元々リクエストされたリソースに対する代わりの参照 ではない。303 レスポンスはキャッシュ可能し てはならない が、二番目 の (リダイレクトされた) リクエストへのレスポンスはキャッシュ可能であ る。 （以下略）
リクエストされたリソースは、一時的に別の URI に属している。（以下略）
| 302 | 303 | 307 | |
|---|---|---|---|
| Reason Phrase | Found | See Other | Temporary Redirect |
| 本来=GET -> リダイレクト先に使うMethod? | GET | GET | GET |
| 本来=HEAD -> リダイレクト先に使うMethod? | HEAD | HEAD | HEAD |
| 本来=POST -> リダイレクト先に使うMethod? | POST (多くの実装ではGET) | GET | POST |
DELETE/PUT/OPTIONSもPOSTと同様。