HTTP 413 Content Too Large(エイチティーティーピーヨンイチサンコンテンツトゥーラージ)とは | 意味や読み方など丁寧でわかりやすい用語解説

HTTP 413 Content Too Largeは、HTTPステータスコードの一つである。これはクライアントエラーを示す4xx系のコードであり、クライアントから送信されたリクエストのペイロードが、サーバー側で処理できる上限サイズを超過した場合に返される。ペイロードとは、リクエストに含まれる主要なデータ部分、例えばフォームから送信されるデータやアップロードされるファイル本体などを指す。このエラーは、ユーザーがウェブサイトを通じて大きなファイルをアップロードしようとしたり、一度に大量のデータを送信しようとしたりする際に頻繁に発生する。サーバーは、自身が処理できるリクエストのサイズに制限を設けており、その制限を超えるリクエストを受け取った際に、処理を拒否してこの413エラーを返すことで、サーバー自身のリソースを保護している。

このエラーが発生する直接的な原因は、WebサーバーやWebアプリケーション、あるいはその手前に位置するプロキシサーバーやロードバランサーが、受け付けるリクエストのボディサイズに上限を設定していることにある。この上限設定は、サーバーの安定稼働とセキュリティを確保するために極めて重要である。もしサイズ制限がなければ、悪意のあるユーザーが意図的に巨大なデータを送りつけることで、サーバーのメモリやディスク容量を枯渇させ、サービスを停止に追い込むサービス妨害攻撃（DoS攻撃）を容易に行うことができてしまう。また、正当なユーザーによるアクセスであっても、予期せぬ巨大なデータがサーバーリソースを過剰に消費し、他のユーザーへのサービス提供に支障をきたす可能性がある。こうしたリスクを回避するため、各コンポーネントにはデフォルトで適切な上限値が設定されている。

具体的な発生シナリオとしては、ユーザーが高解像度の画像や長時間の動画ファイルをウェブフォームからアップロードしようとするケースが最も典型的である。その他にも、大量のデータが含まれるCSVファイルを一括でインポートする機能や、非常に多くの項目を持つフォームからデータを送信する場合にも、このエラーに遭遇することがある。APIを利用したシステム間連携においても、一度に送信するJSONやXMLデータのサイズが大きすぎると、サーバーから413エラーが返却される。

このエラーへの対処法は、クライアント側とサーバー側の両方の観点から考える必要がある。まず、クライアント側、つまりアプリケーションを利用するユーザーやフロントエンド開発者が行える対策としては、送信するデータのサイズを小さくすることが基本となる。例えば、画像をアップロードする前にクライアントサイドでリサイズや圧縮処理を施したり、動画をより効率的な形式にエンコードしたりする方法がある。また、一度に送信するデータ量を減らすために、データを分割して複数回に分けて送信する、いわゆるチャンク分割アップロードを実装することも有効な解決策である。

一方、システムエンジニアが主に対応するのはサーバー側の設定変更である。アプリケーションの要件として、大きなファイルのアップロードが必須である場合は、サーバーが受け付けるリクエストサイズの上限値を引き上げる必要がある。この設定は、システム構成によって変更すべき箇所が異なる。一般的に広く利用されているWebサーバーであるApacheの場合、設定ファイル（httpd.confなど）にあるLimitRequestBodyディレクティブの値を変更することで上限サイズを調整できる。Nginxの場合は、設定ファイル（nginx.confなど）のclient_max_body_sizeディレクティブが該当する。例えば、client_max_body_size 100M;のように記述すると、上限を100メガバイトに設定できる。

Webサーバーだけでなく、その上で動作するWebアプリケーションフレームワーク側にも同様の制限が存在する場合がある。例えば、PHPで開発されたアプリケーションでは、設定ファイルphp.ini内のpost_max_size（POSTデータ全体の上限）とupload_max_filesize（アップロードファイル単体の上限）の両方を適切に設定する必要がある。これらの値がWebサーバーの設定値よりも小さい場合、Webサーバーがリクエストを受け付けても、PHPが処理を拒否してしまうため注意が必要である。

さらに、システム構成が複雑な場合、リクエストはクライアントから直接Webサーバーに届くわけではない。ロードバランサーやリバースプロキシがWebサーバーの前段に配置されているケースでは、これらの機器にもリクエストサイズの制限が設定されている可能性がある。例えば、Nginxをリバースプロキシとして利用している場合、プロキシとしての設定箇所にもclient_max_body_sizeの指定が必要になる。クラウドサービス（AWS, GCP, Azureなど）のロードバランサーを利用している場合も、その管理コンソールから上限サイズの設定を確認・変更する必要がある。問題の切り分けを行う際は、クライアントからサーバーまでの通信経路全体を意識し、どのコンポーネントがエラーを返しているのかをログなどから特定することが重要となる。

ただし、上限値を引き上げる際には注意が必要である。値を無闇に大きく設定すると、前述したセキュリティリスクやサーバーリソースの枯渇リスクを高めることになる。アプリケーションの要件を十分に検討し、必要最小限の適切な値に設定することが求められる。

なお、このステータスコードは、RFC 2616では「Request Entity Too Large」という名称であったが、RFC 7231で「Payload Too Large」に改称された。現在では「Content Too Large」という表現も広く使われているが、いずれも同じ意味を持つエラーコードである。