HTTPの「厳格さ」が命取り？RFC 7230から紐解くHTTP/1.1のメッセージ構文とエラーの深淵
Webエンジニアとして数え切れないほどのトラシューを潜り抜けてきましたが、結局のところ、現場で起きる「謎の400エラー」の9割は、RFCの定めた「規約」に対する甘えが原因です。
現代のAPI開発では、フレームワークがよしなにやってくれるおかげで、HTTPメッセージの構造を意識することは減りました。しかし、ロードバランサーとバックエンドの間で不整合が起きたり、プロキシが介在した瞬間に通信が破綻したりしたとき、頼りになるのは「HTTP/1.1のメッセージ構文」という原点だけです。
今回は、HTTPの憲法とも言える「RFC 7230」を軸に、なぜあなたのリクエストが「400 Bad Request」として突き返されるのか、その技術的背景を深掘りしていきましょう。
—
1. HTTP/1.1メッセージの「骨格」を理解する
HTTP/1.1のメッセージは、非常に厳格なテキストフォーマットで定義されています。まずは、パケットがどのように構成されているかを再確認しましょう。
メッセージ構文の基本
HTTPメッセージは、大きく分けて「開始行（Start-line）」「ヘッダー（Header）」「ボディ（Body）」の3層構造です。
GET /api/v1/resource HTTP/1.1 <-- 開始行: メソッド SP リクエストターゲット SP バージョン CRLF Host: example.com <-- ヘッダーフィールド: フィールド名 ":" SP フィールド値 CRLF Content-Type: application/json <-- ヘッダーは必ずCRLFで終わる <-- 空行: ヘッダーとボディの境界線 (CRLF) {"id": 123} <-- メッセージボディ ここで重要なのは、「CRLF（`\r\n`）」という区切り文字がプロトコルの根幹を支えているという点です。最近の言語では`\n`だけで済ませることも多いですが、RFC 7230の世界では、`\r\n`以外の改行コードは「不正」とみなされる可能性があります。
—
2. なぜ「400 Bad Request」は発生するのか
サーバーが `400 Bad Request` を返すとき、それは「お前のリクエストは構文的に解釈不能だ」という強い警告です。現場でよく遭遇するトリガーをいくつか挙げます。
① 不正なヘッダー名と「スペース」の罠
ヘッダーフィールド名にスペースが含まれていたり、コロンの前にスペースがあったりすると、パーサーは即座にエラーを吐きます。
- NG例: `User- Agent: Mozilla/5.0` （名前の途中にスペースはNG）
- NG例: `Host : example.com` （コロンの前のスペースはNG）
② 無効なリクエストターゲット
リクエスト行のURIに制御文字（ASCIIの0-31や127）が含まれている場合、セキュリティ上の観点からサーバーはリクエストを遮断します。特に、ブラウザがURLエンコードを忘れた状態で特殊記号を投げると、バックエンドがパニックを起こす原因になります。
—
3. 実務でのデバッグ：curlで「構文の境界」を覗く
「ブラウザからは動くのに、API経由だと400になる」という事象は、ヘッダーの付与方法や改行コードに起因することが多いです。そんな時は、`curl`を使って「何が送られているか」をバイナリレベルで可視化しましょう。
-v オプションで詳細な通信内容を表示
–trace-ascii を使うと、ヘッダーの区切り文字(CRLF)まで確認可能
curl -v -X POST “http://example.com/api” \
-H “Content-Type: application/json” \
-d ‘{“data”: “test”}’ \
–trace-ascii debug.txt
debug.txt を確認し、ヘッダーの末尾に \r\n が正しく入っているか確認する
もし自作のクライアント（Pythonの`socket`ライブラリ等）で通信を行っている場合は、必ず `\r\n` を明示的に指定してください。
import socket
ソケット通信でのリクエスト構築例
request = (
“POST /api/data HTTP/1.1\r\n”
“Host: example.com\r\n”
“Content-Type: application/json\r\n”
“Content-Length: 15\r\n”
“\r\n” # 必須の空行
‘{“key”: “value”}’
)
改行コードを \n だけで済ませると、多くのサーバーで400エラーとなる
—
4. インフラ屋の視点：プロキシと「メッセージの不一致」
最後に、インフラ運用の現場で最も怖いのが「リクエストスマグリング」への対策です。
現在のWebサーバー（NginxやApache）は、RFC 7230に従い、`Content-Length`ヘッダーと`Transfer-Encoding`ヘッダーの両方が存在する場合、セキュリティのためにリクエストを拒否するか、特定のルールで優先順位を決定します。
設定のアドバイス:
Nginxなどでリクエストをプロキシする際は、バックエンドに渡す前にヘッダーの整合性をチェックする設定を入れるのが定石です。
Nginxの設定例: 厳格なHTTPヘッダーチェック
http {
# 不正な文字を含むヘッダーを無視せずエラーにする
ignore_invalid_headers on;
# アンダーバーを含むヘッダーを許可するかどうか（API設計による）
underscores_in_headers off;
}
—
最後に：プロトコルへの敬意を
HTTP/1.1は古くからある規格ですが、だからこそ世界中のネットワーク機器やブラウザが共通認識として持っている「共通言語」です。フレームワークの裏側で動いているこの厳格なルールを理解しておくことは、トラブルが発生した際に「どこでパケットが弾かれたか」を嗅ぎ分ける強力な武器になります。
「400 Bad Request」が出たとき、焦ってコードを変える前に、まずは送信しているメッセージをRFC 7230という物差しで測ってみてください。答えは必ずそこにあります。
次回の記事では、HTTP/2におけるバイナリフレーミングが、いかにしてこれらの「テキストベースの苦悩」を解決したのか、その進化の歴史を紐解いていきましょう。それでは、また現場でお会いしましょう。
コメント