HTTP 413 Content Too Large：意味と解決方法

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

• ブラウザ、API クライアント、アップロードツール、または監視チェックが HTTP 413 Content Too Large を受け取ります。
• 大きなファイル、フォーム、JSON ドキュメント、multipart リクエスト、その他のリクエストボディを送信したときにエラーが表示されます。
• 同じリクエストでも、小さいものは成功し、大きいものだけ失敗することがあります。
• レスポンスはプロキシ、CDN、WAF、Web サーバー、またはアプリケーションから返される可能性があり、レイヤーによってヘッダーや本文のテキストが異なる場合があります。
• サイトの他の部分は利用可能なままで、無関係な URL やリクエスト種別は引き続き動作することがあります。
• 413 は HTTP レイヤーのレスポンスであるため、DNS 解決や TLS が正常でも発生する可能性があります。

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

1. リクエストがアップロードまたはボディサイズの制限を超えている。 アプリケーションや Web サーバーが、リクエストボディ、ファイル、フォーム、または multipart の最大サイズを設定している場合があります。
2. 中間コンポーネントの制限がより小さい。 リバースプロキシ、CDN、ロードバランサー、または WAF が、オリジンのアプリケーションにリクエストが届く前に拒否することがあります。
3. より厳しいエンドポイントにルーティングされている。 URL、メソッド、バーチャルホスト、または環境によって、サイズポリシーが異なる場合があります。
4. 設定された制限が一致していない。 プロキシは許可してもアプリケーションが拒否する場合や、アプリケーションは許可してもプロキシがブロックする場合があります。
5. 想定よりリクエストが意図せず大きくなっている。 multipart のオーバーヘッド、サイズの大きいエンコード済みフィールド、添付ファイル、またはデータが重複したクライアントの再試行によって、ボディサイズが増加することがあります。
6. エンドポイントが大きなコンテンツを意図的に拒否している。 API やアップロード用ルートの中には、製品上またはセキュリティ上の制限を設けているものがあります。想定されたポリシーを確認せずに解除すべきではありません。

修正方法

訪問者と API 利用者向け

1. 正確な URL を確認し、何度もリロードを繰り返さずにリクエストを一度だけ再実行します。
2. ファイルをアップロードしている場合は、より小さいファイルを試すか、承認された形式または圧縮方法でファイルサイズを小さくします。
3. API リクエストの場合は、失敗したペイロードを最小限の有効なペイロードと比較します。想定外に大きなフィールド、埋め込みデータ、重複したコンテンツ、multipart の構成ミスがないか確認してください。
4. リクエストが意図したメソッドと Content-Type を使用していることを確認します。エラーを回避するためだけに認証やセキュリティ制御を削除しないでください。
5. 小さなリクエストは成功するものの、必要なリクエストが失敗する場合は、URL、メソッド、おおよそのリクエストサイズ、タイムスタンプ、レスポンスヘッダー、ペイロードのサニタイズ済みの説明をサイト所有者に伝えてください。パスワード、Cookie、トークン、API シークレットは共有しないでください。

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

1. 失敗したリクエストを記録します。 URL、HTTP メソッド、Content-Type、おおよそのボディサイズ、ステータス、レスポンスヘッダー、さらにリクエストがプロキシ、CDN、ロードバランサー、または WAF を経由しているかを記録します。認証情報と個人データはマスキングしてください。
2. サイズを比較して再現します。 最小限の有効なリクエストと、段階的に大きくしたリクエストをテストするか、成功したアップロードと失敗したアップロードを比較します。これにより、設定を早まって変更せずに実効的な制限を確認できます。
3. レスポンスを生成したレイヤーを特定します。 同じタイムスタンプとリクエストについて、レスポンス本文、ヘッダー、アクセスログ、プロキシログ、WAF イベント、アプリケーションログを比較します。リクエストがアプリケーションログに存在しない場合は、上流のコンポーネントが先に拒否した可能性があります。
4. 経路上の制限を比較します。 関係するリクエストボディ、アップロード、multipart、プロキシ、CDN、WAF、アプリケーションの制限を確認します。実効的な制限は、リクエストを拒否する最初のコンポーネントによって決まります。
5. 最も限定的な修正を選びます。 リクエストを受け入れるべき場合は、権限、メモリ、ストレージ、タイムアウト、セキュリティへの影響を確認したうえで、関係するルートまたはコンポーネントだけを調整します。制限が意図されたものであれば、そのまま維持し、クライアントのワークフローを変更するか、サポートされる最大値を文書化します。
6. 元のリクエストパターンを再テストします。 同じメソッド、URL、Content-Type、代表的なペイロードサイズを使用します。受け入れられたリクエストがアプリケーションに到達すること、また不正なリクエストや明らかに大きすぎるリクエストが意図どおり処理され続けることを確認します。
7. 周辺の動作を確認します。 小さなリクエスト、無関係なルート、認証の動作、設定変更の影響を受ける他のプロキシやアプリケーション層をテストします。変更をバージョン管理し、最終的な制限値と変更理由を記録してください。

予防と修正確認

• 各アップロードまたは API ルートでサポートされる最大リクエストサイズ、ファイルサイズ、multipart サイズを文書化します。
• 可能な限り、アプリケーション、Web サーバー、プロキシ、CDN、WAF の制限を可視化し、バージョン管理します。
• リリース前に、非本番環境で境界付近のサイズと代表的な大きなリクエストをテストします。
• 413 のレスポンスをルート、メソッド、クライアント、デプロイごとに監視し、予期しない増加と意図した制限を区別できるようにします。
• クライアントが送信前にファイルとペイロードのサイズを検証し、大きすぎるリクエストに対して明確な代替手段を提示できるようにします。
• シークレットや不要な個人データを記録せずに、どのレイヤーがリクエストを拒否したかを判断できるだけの、サニタイズ済みプロキシログとアプリケーションログを保持します。

よくある質問