ステータスコード307 一時的リダイレクトとは？正確なリダイレクト

オンラインで高額な商品を購入しようとしています。クレジットカード情報を入力し、「今すぐ支払う」ボタンをクリックすると、一瞬だけブラウザが機密データを含むPOSTリクエストを送信します。突然、サーバーが3Dセキュア認証ページにリダイレクトする必要が生じました。この支払い情報を含む元のPOSTリクエストはどうなるのでしょうか？失われてしまうのでしょうか？それとも誤って送信されるのでしょうか？

この重要なシナリオにおいて、HTTPリダイレクトコードの微妙な違いが非常に重要になります。これは、最も正確で価値のあるステータスコードの1つである307 Temporary Redirectの特定の役割です。

その「いとこ」である302 Foundがよく知られた「一時的なリダイレクト」であるのに対し、307はより厳格で信頼性の高い兄弟です。これは、元々のHTTP仕様における決定的な曖昧さを解決するために作成され、支払い処理やフォーム送信のような機密性の高い操作がリダイレクト中に誤って処理されないようにします。

これは、「あそこに行ってください」という漠然とした指示と、「私に渡そうとしていたものすべてを、代わりにあの人に渡してください」という正確な命令の違いのようなものです。

堅牢なウェブアプリケーション、特に支払い、ログイン、データ送信を処理するAPIを構築している開発者にとって、307を理解することは不可欠です。

技術的な詳細に入る前に、複雑なリダイレクトフローを伴うAPIを構築またはテストしている場合、これらのニュアンスを処理できるツールが必要です。Apidogを無料でダウンロードしてください。これは、さまざまなリダイレクトタイプを簡単にテストし、リクエストメソッドが保持されていることを確認し、アプリケーションの重要なパスが安全で信頼できるものであることを保証するオールインワンのAPIプラットフォームです。

button

それでは、ステータスコード307 Temporary Redirectについて詳しく見ていきましょう。

問題：302リダイレクトの曖昧さ

307を理解するためには、まずそれが解決するために設計された欠陥を理解する必要があります。物語は、元々の一時的なリダイレクトである302 Foundから始まります。

HTTP/1.0の302の仕様は曖昧でした。クライアントがリダイレクトを実行すべきだと述べていましたが、リダイレクトされたリクエストが元のリクエストと同じHTTPメソッド（例：POST、PUT）を使用すべきかどうかは明示していませんでした。

これにより問題が生じました。安全上の理由から、ほとんどのブラウザベンダーは、リダイレクトされたリクエストのメソッドをGETに変更することで302を実装しました。これはほとんどの基本的なウェブブラウジングでは理にかなっていましたが、プログラム的またはAPI駆動のインタラクションでは大惨事をもたらしました。

大惨事のシナリオ：

クライアントがフォームデータを/submit-paymentにPOSTします。
サーバーが302 FoundとLocation: /confirmヘッダーで応答します。
ブラウザはGETリクエストを/confirmに送信してリダイレクトに従います。
機密性の高いPOSTデータは失われます。/confirmエンドポイントはGETを期待しているため、ページを表示するかもしれませんが、どの支払いを確定すべきか分かりません。

307ステータスコードは、この危険な曖昧さを完全に排除するためにHTTP/1.1で導入されました。

HTTP 307 Temporary Redirectは実際に何を意味するのか？

307 Temporary Redirectステータスコードは、明確で曖昧さのない指示です。これは、ターゲットリソースが一時的に異なるURIに存在することを示し、ユーザーエージェントはリダイレクトされたリクエストを作成する際に、元のリクエストで使用されたリクエストメソッドを変更してはならないことを意味します。

元のリクエストがPOSTであった場合、リダイレクトされたリクエストもPOSTでなければなりません。PUTであった場合もPUTのままでなければなりません。メソッドとボディは同一でなければなりません。

典型的な307応答は次のようになります。

HTTP/1.1 307 Temporary RedirectLocation: <https://auth.example.com/3d-secureContent-Type:> text/htmlContent-Length: 125
<html><head><title>307 Temporary Redirect</title></head><body><center><h1>307 Temporary Redirect</h1></center></body></html>

すべてのリダイレクトと同様に、鍵となるのはLocation: <https://auth.example.com/3d-secure>ヘッダーです。その魔法は、307ステータスコード自体の意味論的な保証にあります。

HTTPにリダイレクトが存在する理由

リダイレクトは、ユーザーエクスペリエンスを損なうことなく、サーバーとクライアントがリソースの利用可能性の変更を伝えるのを助けるために存在します。

一般的なシナリオには次のようなものがあります。

ウェブサイトの移行 → http://からhttps://への移動。
一時的な停止 → サーバーのメンテナンス中にトラフィックを誘導。
APIのバージョン管理 → クライアントを新しい一時的なエンドポイントに送信。

リダイレクトがなければ、リソースが移動するたびにユーザーはエラーメッセージを見つめることになります。

307 vs. 302: 決定的な違い

これが最も重要な違いです。その違いはすべてメソッドの保持にあります。

機能	`302 Found`	`307 Temporary Redirect`
元の仕様	メソッド変更に関して曖昧。	メソッド変更を明示的に禁止。
典型的なブラウザの動作	POSTをGETに変更。これが決定的な違い。	元のメソッドを保持（POSTはPOSTのまま）。
安全性	安全ではない。非冪等なリクエスト（POSTなど）の後には使用すべきではない。	安全。特に非冪等なリクエストのために設計されている。
例え	「送信された情報は受け取られました。結果を見るためにこの新しいページに行ってください。」（データは引き渡される）。	「全く同じ情報パッケージをこの新しいアドレスに再送してください。」（データはリダイレクトされる）。

どちらをいつ使用するか？

302 Foundは、POST後にリダイレクトしたいが、実際のデータ送信は完了しており、リダイレクトは結果ページを表示するためだけの場合に使用します。（ただし、この目的には303 See Otherの方がさらに優れていることが多いです）。
307 Temporary Redirectは、元のリクエスト（およびそのメソッド/ボディ）をアクションを完了するために別のURIに再送信する必要がある場合に使用します。これは認証フロー、決済ゲートウェイ、APIチェーンで一般的です。

307 Temporary Redirectの仕組み

簡略化されたフローは次のとおりです。

1. クライアントがリソースをリクエストします：

POST /checkout HTTP/1.1
Host: shop.example.com

2. サーバーが307 Temporary Redirectで応答します：

HTTP/1.1 307 Temporary Redirect
Location: <https://secure.example.com/checkout>

3. クライアントは新しい場所でPOSTリクエストを繰り返します：

POST /checkout HTTP/1.1
Host: secure.example.com

重要な点：リクエストメソッドとボディは保持されます。

実世界の例：支払いフロー

307が実際にどのように機能するか、支払いシナリオを見てみましょう。

1. 元のPOST：ユーザーが支払いフォームを送信します。ブラウザは以下を送信します。

POST /checkout/payment HTTP/1.1Host: shop.example.comContent-Type: application/x-www-form-urlencoded

card_number=4111...&expiry=12/25&cvc=123

2. サーバーの307応答：ショップのサーバーは銀行の3Dセキュアシステムに処理を渡す必要があります。サーバーは以下で応答します。

HTTP/1.1 307 Temporary RedirectLocation: <https://api.bank.com/3d-secure/authenticate>

3. 保持されたPOST：ブラウザは307応答を受け取ります。仕様が明確であるため、ブラウザは全く同じPOSTリクエストと全く同じボディを新しい場所に再送信しなければならないことを知っています。

POST /3d-secure/authenticate HTTP/1.1Host: api.bank.comContent-Type: application/x-www-form-urlencoded

card_number=4111...&expiry=12/25&cvc=123

4. 最終結果：銀行のAPIは支払い詳細を直接受け取り、認証を実行し、次のステップ（おそらくショップの確認ページへの303または302リダイレクト）をクライアントに応答します。

このフローにより、ショップと銀行の間で機密データが失われることはありません。

307と301または302の使い分け

301 Moved Permanently → リソースの場所が二度と変更されない場合。
302 Found → リソースが一時的に別の場所にあるが、メソッドの保持が重要ではない場合。
307 Temporary Redirect → リソースが一時的に別の場所にあるが、HTTPメソッドを保持する必要がある場合。

経験則として：

永続的な変更には301を使用します。
機密性の高い操作（POSTリクエストなど）を伴う一時的な移動には307を使用します。

307 Temporary Redirectを使用する利点

予測可能性 → リクエストメソッドは常に保持されます。
セキュリティ → 意図しないメソッドのダウングレード（例：POSTがGETに変わる）を防ぎます。
開発者の明確さ → クライアントは期待される動作を正確に知ることができます。

欠点とよくある誤解

一部の古いクライアントは307を正しく処理できない場合があります。
開発者が307と302を混同し、意図しない動作につながることがあります。
SEO専門家が307を301と同等であると誤解することがありますが、そうではありません。

307とAPI開発

APIの世界では、307は重要な役割を果たします。

非冪等なリクエスト（POSTなど）の一貫性を保証します。
一時的な変更中にAPIゲートウェイがトラフィックを安全にルーティングするのに役立ちます。
メンテナンス期間を安全に処理する方法を提供します。

307がなければ、開発者はクライアントが意図せずにリクエストタイプを変更するリスクを負うことになります。

Apidogで307リダイレクトをテストする

この動作をテストすることは非常に重要です。APIを構築またはテストしている場合、クライアントが307応答をどのように処理するかを確認したいと思うでしょう。クライアントがメソッドとボディを保持して307応答を正しく処理することを確認する必要があります。Apidogはこれに最適なツールです。

Apidogを使用すると、次のことができます。

POSTリクエストを作成する：JSONまたはフォームデータボディを含むPOSTリクエストをエンドポイントに簡単に設定できます。
307応答をモックする：Apidogでサーバーモックを設定し、Locationヘッダー付きの307 Temporary Redirectを返すようにします。
自動リダイレクトを観察する：Apidogは自動的にリダイレクトに従います。重要なテストは、2番目のリクエストのリクエストログをチェックすることです。POSTメソッドは保持されましたか？全く同じボディが送信されましたか？
302と比較する：同じテストを実行し、モックが代わりに302を返すようにします。Apidog（標準ブラウザのように動作）がメソッドをGETに変更し、ボディを破棄する様子を観察します。この視覚的なデモンストレーションは、違いを完璧に示します。
APIクライアントをテストする：プログラム的なAPIクライアント（Node.js、Pythonなど）を構築している場合、Apidogを使用してサーバーをモックし、クライアントコードがメソッドを保持して307応答を正しく処理することを確認できます。

button

このレベルのテストにより、支払い処理やログインなどの重要な操作が本番環境で中断されないことが保証されます。Apidogを無料でダウンロードして、今日307応答のモックを試してみてください。これは、実際のリアルタイムリダイレクト条件下でアプリケーションをテストするのに最適な方法です。

307 Temporary RedirectのSEOへの影響

SEOの観点から：

307は検索エンジンにリダイレクトが一時的なものであることを伝えます。
301とは異なり、検索エンジンは新しいURLにリンクの価値（PageRank）を転送しません。
これはA/Bテスト、プロモーション、短期的なキャンペーンに最適です。

301の代わりに307を使用すると、長期的なSEO上の利益を失うリスクがあります。

307 vs. 308 Permanent Redirect

307が302の厳格な対応物であるのと同様に、永続的な移動のための兄弟がいます：308 Permanent Redirect。

307 Temporary Redirect：「一時的に同じリクエストをこの別のURLに再送信してください。」
308 Permanent Redirect：「永続的に同じリクエストをこの別のURLに再送信してください。記録を更新してください。」

一時的なメンテナンス、A/Bテスト、またはフェイルオーバーのシナリオには307を使用します。非GETリクエストを期待するエンドポイントのURLを永続的に変更する場合は308を使用します。

307に関するセキュリティ上の考慮事項

セキュリティ面では、307はリクエスト操作を回避するため、302よりも安全なことが多いです。ただし、次の点に留意してください。

悪意のあるリダイレクトによって、ユーザーがフィッシングサイトに誘導される可能性があります。
ダウングレード攻撃を防ぐために、Locationヘッダーでは常にHTTPSを使用してください。

実装とベストプラクティス

サーバー開発者向け：非冪等なリクエスト（POST、PUT、DELETE）を一時的にリダイレクトする必要がある場合は、307を使用してください。これは最も安全で意味的に正しい選択です。
クライアント開発者向け：HTTPクライアントライブラリ（例：Axios、Requests）が、元のリクエストを新しい場所に再送信することで307応答を正しく処理することを確認してください。ほとんどの最新のライブラリはこれを正しく行います。
常に正確さを優先する：メソッドを保持する必要があることが確実な場合は、302よりも307を使用することをデフォルトにしてください。これにより曖昧さが解消されます。

307 Temporary Redirectの代替手段

ユースケースに応じて：

移動が永続的でメソッドの保持が必要な場合は、308 Permanent Redirectを使用します。
メソッドが重要ではなく、後方互換性がより重要な場合は、302 Foundを使用します。
SEOが優先される永続的なリロケーションには、301 Moved Permanentlyを使用します。

結論：安全性の保証

HTTP 307 Temporary Redirectステータスコードは、ウェブがより高い精度と安全性に向かって進化していることの証です。これは、データ損失やセキュリティ脆弱性につながる可能性のあるプロトコルの重要な曖昧さを解決しました。

307 Temporary Redirectステータスコードは、HTTP仕様における単なる数字以上のものです。リダイレクト中にリクエストメソッドとボディが損なわれずに維持されることを保証することで、現実世界の問題を解決します。

302や303にはそれぞれの役割がありますが、307は、その宛先が一時的に変更された場合でも、リクエストが意図したとおりに正確に配信されるという重要な保証を提供します。これにより、機密性の高い操作を処理する信頼性の高い安全なウェブアプリケーションを構築するために不可欠なものとなっています。

これらのリダイレクトコード間の微妙な違いを理解することは、シニア開発者の証です。そして、アプリケーションがこれらのリダイレクトを正しく処理することを確認し、検証する際には、Apidogのような強力なツールが、リダイレクトが機能しているだけでなく、正確に機能していることを保証するために必要な可視性と制御を提供します。

button