HTTP 302 Foundとは：その意味

このエラーの意味と見分け方

• ブラウザー、APIクライアント、稼働監視、HTTPチェッカーが302 Foundを報告する。
• レスポンスにLocationヘッダーが含まれる、またはクライアントが別のURLへ移動する。
• ブラウザーではリクエストが機能するように見えるが、リダイレクトの処理方法が異なるため、APIクライアントでは失敗する。
• POSTなどのGET以外のリクエストがリダイレクトされ、追従後のリクエストが期待どおりに動作しない。
• ほかのURLは正常に動作する一方で、特定のルート、ホスト、リクエストメソッド、認証状態、またはクライアントだけが影響を受ける。
• リクエストがHTTP対応エンドポイントに到達しているため、DNSは解決しTLSも有効な場合があります。これらの確認はリダイレクトレスポンスとは別に行います。

可能性の高い順の主な原因

1. 意図的な一時ルーティング： 一時的な変更やワークフローのため、アプリケーションまたはWebサーバーがユーザーをあるURLから別のURLへ移動させる。
2. 認証またはセッション処理： 未認証のリクエストがサインインまたはセッション関連のルートへリダイレクトされる。
3. アプリケーションロジック： ルート、ロケール選択、フォームワークフロー、機能フラグ、リクエスト状態のルールが、特定のユーザーやメソッドに対してリダイレクトを返す。
4. リバースプロキシ、CDN、WAFの設定： インターミディエリが、リクエストをオリジンのアプリケーションへ到達させる前にリダイレクトを適用する。
5. キャッシュまたは古い設定： キャッシュされたレスポンスや、最近変更されたルーティングルールによって、予期しないリダイレクトが引き続き発生する。
6. メソッドまたはリダイレクトのセマンティクスの不一致： 追従後のリクエストで元のメソッドとリクエストボディを保持する必要がある場合、302が適切でないことがあります。ステータスを変更する前に、クライアントの挙動を確認してください。

ステータスコードだけでは、どのコンポーネントがレスポンスを生成したかを特定できず、ウェブサイト全体に問題があることも証明できません。

修正方法

訪問者とAPIユーザー向け

1. 正確なURLを一度再試行し、スキーム、ホスト名、パス、クエリ文字列、スペルを確認します。
2. クライアントがリダイレクトに自動追従するか確認します。追従する場合は、最終ページだけでなく、元の302レスポンスと最終レスポンスを比較します。
3. ルートに認証が必要な場合は、通常のサイトフローでサインインしてから再試行します。見慣れない移動先に認証情報を送信しないでください。
4. APIリクエストが影響を受けている場合は、メソッド、リクエストURL、レスポンスステータス、Locationの値、最終レスポンスを記録します。ブラウザーでのリダイレクトが有効なAPIの挙動だと決めつけないでください。
5. 移動先で障害が発生している場合や、サービスがリクエスト制限を適用している場合は、更新を繰り返さないでください。
6. リダイレクトが予期しないまま続く場合は、URL、メソッド、タイムスタンプ、クライアントの挙動、サニタイズ済みのレスポンス詳細をサイト所有者に送ります。パスワード、Cookie、認証ヘッダー、APIシークレットは共有しないでください。

サイト所有者と開発者向け

1. 正確なリクエストを再現します。 HTTPメソッド、完全なURL、ホスト、認証状態、ユーザーエージェント、ステータス、Locationヘッダー、クライアントがリダイレクトに追従したかを記録します。ブラウザーの最終ページでは元の302が隠れる場合があります。
2. リダイレクトが意図されたものか確認します。 ルートとメソッドを、文書化されたルーティング、認証、ロケール、メンテナンス、アプリケーションのワークフローと比較します。
3. 生成元のレイヤーを特定します。 レスポンスヘッダーを確認し、リクエストのタイムスタンプをアプリケーション、Webサーバー、リバースプロキシ、CDN、WAFのログと照合します。インフラストラクチャと権限で許可される場合に限り、オリジンへのパスを個別にテストします。
4. リダイレクト先を確認します。 Locationの値が意図したスキーム、ホスト、パス、クエリパラメーターを使用していることを確認します。リダイレクトチェーン、ループ、意図しないホスト名、エラーを返す移動先がないか確認します。
5. リクエストメソッドを比較します。 影響を受けたメソッドをGETとは別にテストします。リクエストでメソッドとボディを保持する必要がある場合は、アプリケーションの設計とクライアントの挙動から、メソッドを保持するリダイレクトステータスが必要か確認します。
6. 最近の変更を確認します。 デプロイと、ルーティング、認証、セッション処理、プロキシルール、CDNの挙動、WAFポリシー、キャッシュへの変更を比較します。
7. 安全で最小限の修正を適用します。 適切な権限とロールバック計画のもと、原因となっているルールまたはコンポーネントだけを変更します。302をなくすためだけに認証やセキュリティ制御を無効化しないでください。
8. 同じリクエストを再テストします。 意図したステータス、移動先、メソッドの処理、ヘッダー、最終レスポンスを確認します。その後、関連するルート、認証済み・未認証の状態、重要なAPIメソッドをテストします。

予防と修正確認

• ルート、HTTPメソッド、ホスト、レスポンスステータス、デプロイごとにリダイレクト率を監視し、予期しない302の変化を把握できるようにします。
• アプリケーションのルーティング、認証、プロキシ、CDN、WAF、キャッシュの設定をバージョン管理します。
• リリース後、重要なページとAPIエンドポイントについて、元のレスポンスと最終移動先の両方をテストします。
• これらのパスでサポートされる場合は、認証済み、未認証、GET以外のリクエストを含めてテストします。
• 意図的な一時リダイレクト、その移動先、影響を受けるメソッド、削除または見直しの予定を文書化します。
• リダイレクトインシデントを関連付けられるよう、適切にサニタイズしたサーバーとアプリケーションのログを十分な期間保持します。
• 設定レビュー時にリダイレクトチェーンと移動先の所有権を確認し、ループや意図しないホスト変更を防ぎます。

よくある質問