HTTP 414 URI Too Long：意味と解決方法

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

• ブラウザー、APIクライアント、クローラー、監視ツール、チェッカーが、HTTP 414 URI Too Longレスポンスを受け取る。
• 問題のアドレスに、異常に長いパス、クエリ文字列、繰り返しパラメーター、または大量にエンコードされたデータが含まれている。
• 短いURLは引き続き動作する一方で、特定のリンク、ルート、リダイレクトチェーン、リクエストタイプだけに問題が発生する場合がある。
• リダイレクトのたびにURLが長くなり、中継装置またはオリジンサーバーが拒否することがある。
• レスポンスヘッダーには、アプリケーションではなくWebサーバー、リバースプロキシ、CDN、WAF、キャッシュ層が示される場合がある。
• リクエストがHTTP対応のエンドポイントに到達しているため、DNS名前解決とTLSネゴシエーションは成功することがある。

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

最も可能性の高い原因

1. 過大なクエリ文字列。 検索、フィルター、トラッキング、ページネーション、状態管理用のパラメーターが、エンドポイントで受け付けられる量を超えるデータをシリアライズしている可能性があります。
2. URL生成のバグ。 クライアント側またはサーバー側のコードが同じパラメーターを繰り返し追加したり、エンコード済みのURLを重複させたり、URIに含めるべきでないデータを配置したりすることがあります。
3. 増大するリダイレクトチェーン。 リダイレクト先が、リターンURL、トラッキングパラメーター、元のアドレスをエンコードしたコピーを繰り返し追加することがあります。
4. プロキシ、CDN、WAF、Webサーバーの制限。 アプリケーションに到達する前にリクエストが拒否されることがあり、各層でURIの制限が異なる場合もあります。
5. 予期しないリクエストの組み立て。 不正なエンコード、別のパラメーター内に誤って含められた絶対URL、壊れたインテグレーションによって、異常に長いリクエストターゲットが生成されることがあります。
6. 意図的なリクエスト検証または不正利用対策。 リソース消費を抑えたり、疑わしいトラフィックをブロックしたりするために、コンポーネントが異常に大きなリクエストターゲットを拒否する場合があります。

修正方法

訪問者とAPIユーザー向け

1. 正確なアドレスを確認する。 繰り返し指定されたクエリパラメーター、トラッキングデータを含むコピー済みURL、不完全なリダイレクト、予想外に長いエンコード済みの値がないか確認します。
2. 安全に実行できる場合は、オプションのパラメーターなしでベースルートを開きます。 短いアドレスが動作するなら、トリガーを特定するためにフィルターやパラメーターを少数ずつ戻します。
3. 繰り返し更新しない。 URIが長すぎる状態は再試行しても短くならず、リダイレクトまたはクライアントのループが関係している場合は負荷を増やす可能性があります。
4. 文書化されたリクエスト形式を使用する。 APIが大きなフィルターやペイロードをリクエストボディで送信できる場合は、文書化された方法に限って使用します。エラーを回避するためだけにGETからPOSTへ変更しないでください。
5. サイトまたはAPIの所有者に連絡する。 サニタイズしたURLまたはリクエストパターン、発生時刻、クライアント情報、414レスポンスを伝えます。Cookie、認証ヘッダー、APIキー、その他の秘密情報は削除してください。

開発者向け

1. リクエストを正確に取得する。 HTTPメソッド、ホスト、パス、クエリ文字列の長さ、リダイレクト履歴、最終ステータス、関連するレスポンスヘッダーを記録します。認証情報と個人データはマスキングしてください。
2. 最小限の失敗リクエストで再現する。 レスポンスが変わるまで、オプションのパラメーターを1つずつ削除するか、値を短くします。これにより、URIサイズの問題とルーティングまたは認証エラーを区別できます。
3. URLの生成処理を調査する。 検索フィルター、ページネーション、トラッキングパラメーター、リターンURL、入れ子になったエンコード、現在のURLを繰り返し追加するループを確認します。
4. リダイレクトを確認する。 チェーン内の各Locationの値を比較し、前のURLや重複パラメーターを追加し続けていないことを確認します。
5. 適切なデータ転送方法を選ぶ。 安全でキャッシュ可能なリソース取得に必要な識別子はURIに保持しつつ、より大きな入力については、セマンティクスとセキュリティモデルが許す場合に、アプリケーションがサポートするリクエストボディの設計を使用します。
6. 生成元の層を確認する。 時刻とリクエストの詳細を、アプリケーション、Webサーバー、リバースプロキシ、CDN、WAFのログと照合します。拒否を最初に記録したコンポーネントが、通常、調査すべき層です。
7. 最も限定的な修正を適用する。 サーバーまたは中継装置の制限を変更する前に、URL生成、リダイレクトロジック、パラメーター処理を修正します。制限を変更する必要がある場合は、許可を取得し、リソースとセキュリティへの影響を評価し、適切な層を更新して代表的なルートをテストします。
8. 元のリクエストと関連するケースを再テストする。 意図したリクエストが成功し、不正または過大なリクエストが適切に制御され、リダイレクトが終了し、関連しないルートが想定どおりのステータスコードを維持していることを確認します。

予防と修正確認

• アプリケーションのバリデーションで、クエリパラメーター数と値の長さに上限を設ける。
• リダイレクトコードが現在のURLを繰り返し入れ子にしたり再エンコードしたりしないようにする。
• 長いフィルター、ページネーション、トラッキングパラメーター、リダイレクトチェーンをインテグレーションテストで検証する。
• プロキシ、CDN、WAF、Webサーバー、アプリケーションの設定を文書化し、対応している場合はバージョン管理する。
• ルート、クライアント、デプロイごとに414レスポンスを監視し、URL生成のリグレッションを把握できるようにする。
• 大きなデータをURLにエンコードするのではなく、大きなアプリケーション入力にはサポートされているリクエストボディを使用する。
• 認証情報や機密データをURLに含めない。URLは履歴、ログ、リファラーデータに記録される可能性がある。

よくある質問