HTTP 400 Bad Request(エイチティーティーピー ヨンヒャク バッド リクエスト)とは | 意味や読み方など丁寧でわかりやすい用語解説
HTTP 400 Bad Request(エイチティーティーピー ヨンヒャク バッド リクエスト)の意味や読み方など、初心者にもわかりやすいように丁寧に解説しています。
読み方
日本語表記
HTTP 400 不正なリクエスト (エイチティーティーピー ヨンヒャク フセイナ リクエスト)
英語表記
HTTP 400 Bad Request (エイチティーティーピー ヨンヒャク バッド リクエスト)
用語解説
HTTPステータスコードは、Webサーバーがクライアントからのリクエストに対してどのように応答したかを示す3桁の数字である。このうち、4xx系のコードは「クライアントエラー」を示し、リクエストを送信したクライアント側に問題があることを意味する。HTTP 400 Bad Requestは、クライアントが送信したHTTPリクエストがサーバーによって不正であると判断された場合に返されるステータスコードだ。これは、サーバーがリクエストの構文を解析できなかったり、リクエストがサーバーのセキュリティポリシーに違反すると判断されたりするなど、リクエスト自体に何らかの問題があることを示す。つまり、サーバー側の処理能力やリソースの問題ではなく、リクエストの形式や内容が期待される基準を満たしていないことが原因となる。
HTTP 400 Bad Requestが発生する具体的な原因は多岐にわたるが、主にクライアントが送信するリクエストの構造や内容に関するものが多い。
最も一般的な原因の一つは、HTTPリクエストの構文エラーである。HTTPプロトコルは厳格なフォーマットに従ってリクエストを構成する必要がある。例えば、リクエストライン(HTTPメソッド、リクエストURI、HTTPバージョン)やHTTPヘッダーフィールドの記述に誤りがある、不正な文字コードや特殊文字が含まれている、改行コードの使い方が間違っている、または予期しない文字が混入している場合などがこれに該当する。サーバーはこれらの構文エラーを検出すると、リクエストを正しく解釈できないため、処理を拒否し400エラーを返す。
次に、リクエストに含まれるパラメータや値の不正が挙げられる。WebアプリケーションやAPIでは、クライアントはしばしばクエリパラメータ、フォームデータ、またはJSONやXML形式のボディデータとして、特定の情報をサーバーに送信する。これらのデータがサーバー側で期待される形式(データ型、値の範囲、文字列の長さなど)を満たしていない場合、400エラーが発生する。例えば、数値が期待されるフィールドに文字列が送信された、必須のパラメータが欠落している、あるいは許可されない範囲外の値が提供された、不正な形式の日付やメールアドレスが送信された、などが典型的だ。サーバー側のバリデーションルールに合致しないデータは、不正なリクエストとして扱われる。
HTTPヘッダーの不正または不足も原因となりうる。例えば、POSTリクエストでJSONデータを送信しているにもかかわらず、Content-Typeヘッダーがapplication/jsonではなく別の値になっているか、あるいはまったく指定されていない場合、サーバーは送信されたボディデータをどのように解釈すればよいか判断できないため、400エラーを返すことがある。また、Content-Lengthヘッダーが実際に送信されたボディデータのサイズと一致しない場合や、サーバーが処理できない、または許可しない不正なカスタムヘッダーが含まれている場合も同様だ。
さらに、リクエストサイズ超過も400エラーの原因となることがある。サーバーは、悪意のある大量データ送信によるサービス拒否攻撃(DoS攻撃)を防ぐ目的や、単純にリソースの過剰な消費を避けるために、受信できるHTTPヘッダーやリクエストボディの最大サイズに上限を設定している。クライアントがこの上限を超える非常に大きなデータを送信しようとすると、サーバーはリクエストを処理せずに400エラーを返す。
不正なクッキー情報が原因となるケースもある。クライアントが保持しているクッキーが破損していたり、サーバーによって設定されたクッキーの形式と異なっていたりする場合、その不正なクッキーを含むリクエストがサーバーに送信されると、サーバーはこれを不正なリクエストと判断し、400エラーを返すことがある。
最後に、セキュリティポリシー違反も重要な原因だ。現代のWebアプリケーションでは、SQLインジェクションやクロスサイトスクリプティング(XSS)といった脆弱性を悪用しようとする攻撃からシステムを保護するためのセキュリティメカニズムが導入されている。サーバーは、リクエストのURL、パラメータ、ヘッダー、またはボディの内容が、これらの既知の攻撃パターンに合致すると判断した場合、セキュリティポリシーに違反する不正なリクエストとして扱い、400エラーを返すことで処理を拒否する。これは、システムを保護するための正当な防御策である。
HTTP 400 Bad Requestエラーが発生した場合、システムエンジニアを目指す初心者としては、まずクライアントが送信したリクエストの内容を詳細に確認することが最も重要となる。Webブラウザを使用している場合は、開発者ツール(通常はF12キーで開くことができる)の「ネットワーク」タブを開き、問題のリクエストをクリックして、そのリクエストのURL、HTTPメソッド、リクエストヘッダー、および送信されたボディデータ(フォームデータやペイロード)を検証する。APIクライアントやスクリプトを使用している場合は、送信されるリクエストのログや設定ファイルを再確認する。
特に、APIを利用している場合は、当該APIの公式ドキュメントを参照し、期待されるリクエストの形式、必須パラメータ、データ型、許可される値の範囲、ヘッダーの要件などを入念に照合することが解決への近道となる。多くの場合、サーバーは400エラーとともに、レスポンスボディにエラーの詳細を示すメッセージを含めている。このメッセージは「Required parameter 'userId' is missing」や「Invalid format for 'dateOfBirth'」のように具体的な内容であることが多く、原因特定の強力な手がかりとなるため、必ず確認すべきである。
一時的なネットワークの問題やサーバー側の瞬間的なエラーの可能性もゼロではないが、400エラーは基本的にクライアント側に起因するため、リクエストの内容を適切に修正し、再度送信することで解決を目指すのが基本的なアプローチとなる。場合によっては、ブラウザのキャッシュやクッキーが古い、あるいは破損した情報を持っていることが原因でエラーが発生することもあるため、これらをクリアして試すことも有効な手段である。システム開発者側としては、クライアントが理解しやすい明確なエラーメッセージを返すようにAPIを設計することや、入力値のバリデーションを適切に行うことが、このようなエラーの発生を抑制し、ユーザーや他の開発者が問題を解決しやすくするために極めて重要だ。