RFC 7230の厳格な世界：HTTP/1.1メッセージ構文と「400 Bad Request」の深層
ネットワークの配管工として長く生きていると、HTTPというプロトコルが「いかにフラジャイルで、同時にいかに強固な合意形成の上になり立っているか」に毎度驚かされる。ブラウザのURLバーに文字を打ち込めば、あたかも魔法のようにページが描画されるが、その裏側ではTCPの3ウェイハンドシェイクが完了した瞬間から、文字通り「1バイトの妥協も許さない」厳格な構文の応酬が始まっている。
今回は、HTTP/1.1のバイナリの土台を規定する「RFC 7230」に焦点を当てる。特に、メッセージ構文の厳密なパース規則と、それが崩壊した瞬間にリバースプロキシやWebサーバが吐き出す「400 Bad Request」の深淵なるトリガーについて、パケットの挙動とLinuxカーネルのバッファリングの視点を交えながら解き明かしていこう。
—
1. 始まりの行（Start-line）とヘッダーの文法解剖学
HTTP/1.1はテキストベースのプロトコルである。だが、それは「人間にとって読みやすい」という意味であって、「曖昧さが許される」という意味では毛頭ない。RFC 7230のセクション3は、メッセージの構造を残酷なまでに正確に定義している。
HTTP-message = start-line
( header-field CRLF )
CRLF
[ message-body ]
このわずか数行の規定に、どれほどのトラップが潜んでいるか。現場で遭遇する障害の多くは、この `CRLF`（Carriage Return / Line Feed, `\r\n`）の解釈のズレや、許容文字コード（ABNFで定義されたオクテットの範囲）の逸脱に起因する。
リクエスト行のパースとGrammarの罠
リクエストメッセージの開始行（Request-Line）は、以下の要素が単一のスペース（SP, ASCII 32）で区切られている必要がある。
GET /index.html HTTP/1.1\r\n
ここでプロキシサーバやWAF（Web Application Firewall）が厳格にチェックするのが、メソッドの大文字小文字、URIのエンコーディング、そしてHTTPバージョン文字列の厳密な合致だ。例えば、HTTP/1.1のパーサーは `HTTP/1.1` という文字列をバイト単位で期待している。ここに `http/1.1` や `HTTP/1.0` が混ざった瞬間、あるいはバージョンサフィックスに余計なゴミが含まれている場合、サーバは即座に処理を放棄する。
ヘッダーフィールドの「目に見えない」脅威
ヘッダーフィールドは `field-name “:” OWS field-value OWS` （OWSはOptional Whitespace）という構造を持つ。ここでインフラエンジニアとして注意しなければならないのが、「コロン（ `:` ）の前の空白」の存在だ。
RFC 7230のセクション3.2.4では、フィールド名とコロンの間の空白を明確に禁止している。
完全に不正なヘッダー（RFC 7230違反）
Host : example.com\r\n
レガシーな一部の脆弱なパーサーはこの不正な空白を許容してしまうことがあるが、NginxやHaproxy、あるいは最新のEnvoyといったモダンなプロキシは、これを受信した瞬間にパーサーエラーを検出し、バックエンドへ転送することなくその場でクライアントを切り捨てる。これが「400 Bad Request」を生む最初の扉である。
—
2. 400 Bad Request：なぜサーバは怒るのか？
「400 Bad Request」は、単なるエラーコードではない。それは「あなたの送ってきたパケットの構造が、HTTP仕様書の定めた文法規則に違反しているため、私はその意味を理解すらできません（あるいは理解することを拒絶します）」という、サーバからの冷徹な宣言である。
実務において、400 Bad Requestが発生する代表的なシナリオをパケットとカーネルの挙動から紐解いてみよう。
シナリオA: 巨大すぎるリクエストヘッダー (Header Overflow)
CookieやOAuthのJWTトークンが肥大化しすぎると、HTTPリクエストヘッダー全体が数キロバイト、あるいは十数キロバイトに達する。
LinuxカーネルのTCP受信バッファには余裕があっても、Webサーバ（Nginxなど）のアプリケーション層バッファ（例: `client_header_buffer_size` や `large_client_header_buffers`）の制限を超えた場合、サーバはヘッダーの途中であっても読み込みを打ち切り、400を返す。
以下は、Nginxでこの制限をチューニングするための設定例だが、安易に数値を引き上げることはセキュリティリスク（後述するHTTPリクエストスマグリングの温床）に直結する。
http {
# 標準的なヘッダーバッファサイズを8kに設定（デフォルトは1kまたは2k）
client_header_buffer_size 8k;
# 大きなCookieや多数のヘッダーを持つリクエスト用のバッファプール
large_client_header_buffers 4 16k; # 16キロバイトのバッファを最大4つまで確保
}
シナリオB: トランスポート層の不整合とContent-Lengthの競合
メッセージボディを持つリクエスト（POSTやPUT）において、RFC 7230はボディの長さを決定する方法として `Transfer-Encoding: chunked` と `Content-Length` のどちらを使うか、あるいは両方使う場合の厳格なルールを定めている。
もし、ひとつのリクエストに `Transfer-Encoding` と `Content-Length` の双方が矛盾する形で含まれていた場合、あるいは不正なチャンクサイズ（16進数以外の文字や、負の値）が検出された場合、サーバはパケットの解釈を即座に停止する。これは、後述するセキュリティ脆弱性を防ぐための必須の防衛機制である。
—
3. 脆弱性とHTTPパーサー：HTTPリクエストスマグリングの脅威
RFC 7230の構文規則を厳格に守らなければならない最大の理由は、単なる仕様の美しさではない。「HTTPリクエストスマグリング（HTTP Request Smuggling）」をはじめとする致命的なセキュリティ脆弱性を回避するためだ。
フロントエンドとバックエンドの「解釈のズレ」
現代のWebアーキテクチャは、NginxやAWS ALBなどの「リバースプロキシ（フロントエンド）」の背後に、GunicornやNode.js、Tomcatなどの「アプリケーションサーバ（バックエンド）」が控える多層構造が基本となっている。
もし、フロントエンドのプロキシが「甘いパーサー」で実装されており、RFC 7230違反のリクエスト（例えば、不正な `Content-Length` の二重定義や、予期せぬスペース）を「良かれと思って勝手に補正（Normalization）」してバックエンドに転送してしまったらどうなるか？
[クライアント] —> (不正なHTTPメッセージ) —> [フロントエンド (甘い解釈)] —> (変形されたメッセージ) —> [バックエンド (厳格な解釈)]
フロントエンドが「これは1つのリクエストだ」と解釈したパケットを、バックエンドが「いや、これは2つのリクエスト（前半のボディが後半のリクエストの開始行に化けている）だ」と誤認した瞬間、攻撃者はフロントエンドの背後をすり抜けて、任意のHTTPリクエストをバックエンドに「密輸（スマグリング）」することが可能になる。これにより、キャッシュポイズニングや、認証バイパス、別ユーザーのセッションハイジャックが引き起こされる。
RFC 7230が課す「厳格性（Strictness）」の哲学
このリスクに対抗するため、近年のインフラストラクチャにおけるHTTPパーサーは、RFC 7230のルールに少しでも違反するパケット（例: ヘッダー名に含まれる不正な文字、不審な区切り文字）を一切許容せず、一律で400 Bad Requestとして拒絶する仕様へとシフトしている。
「寛容な受信側であれ（Postliberty of implementation: Be conservative in what you send, be liberal in what you accept）」という古いインターネットの格言は、セキュリティが最優先される現代のネットワークにおいては「受信において厳格であれ（Be strict in what you accept）」へと完全に塗り替えられたのだ。
—
4. パフォーマンスとスループットの限界を引き出すチューニング
構文の厳格さを維持しつつ、極限のパフォーマンスを叩き出すためには、ネットワークスタックとHTTPレイヤーのチューニングが不可欠である。特に高トラフィックなAPIゲートウェイを構築する場合、以下のパラメーターと挙動の理解が明暗を分ける。
TCPレイヤーとTLSハンドシェイクの最適化
HTTP/1.1はTCPの「ヘッド・オブ・ライン・ブロック（HoLB: Head-of-Line Blocking）」の影響を受けるため、コネクションの効率的な使い回し（Keep-Alive）が命綱となる。
LinuxカーネルのTCPスタックにおいて、HTTP/1.1の小規模なリクエスト/レスポンスの往復性能を最大化するためには、NagleアルゴリズムとTCP_NODELAYの制御が重要になる。
// ソケット作成時にTCP_NODELAYを有効化し、小さなパケットの送信遅延（Nagleアルゴリズムによる200msの待機）を排除する
int flag = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char )&flag, sizeof(int));
さらに、TLS 1.3環境下であれば、早期データ送信（0-RTT）を活用することでハンドシェイクのラウンドトリップを削減できるが、HTTPリクエストの安全性を担保するため、0-RTTで送信されるデータは「リプレイ攻撃」に対して安全なべき等（Idempotent）なメソッド（GET等）に限定されるべきである。ここでもRFC 7230のメソッド定義（GET, POSTなどのセマンティクス）がセキュリティの基盤として生きてくる。
キープアライブ（Keep-Alive）とタイムアウトの設計
HTTP/1.1ではデフォルトで持続的接続（Persistent Connection）が有効だが、無限にコネクションを維持することはサーバのリソース枯渇（ファイルディスクリプタの圧迫）を招く。
Nginx等の実運用における最適なタイムアウト設計の例：
http {
# アイドル状態の持続的接続を保持する時間（長すぎるとC10K問題ならぬC10M問題の温床になる）
keepalive_timeout 65;
# 1つのKeep-Aliveコネクション上で処理できる最大リクエスト数
keepalive_requests 1000;
# クライアントからのリクエストヘッダー読み取りタイムアウト
client_header_timeout 10s;
# クライアントからのリクエストボディ読み取りタイムアウト
client_body_timeout 10s;
}
これらのタイムアウト値を適切に短く設定することで、悪意あるスロースロリス（Slowloris）攻撃――極端に遅い速度でHTTPヘーダーを送り続け、サーバの接続スレッドを占有する攻撃――を防ぐことができる。
—
結び：パケットの細部に宿るプロトコルの魂
HTTP/1.1という、一見すると枯れ切ったプロトコル。その基礎規定であるRFC 7230は、私たちが日頃何気なく叩くWebの裏側で、厳格な文法解釈と、巧妙なセキュリティの攻防が繰り広げられていることを教えてくれる。
「たかが400 Bad Request、されど400 Bad Request」。
もしあなたが構築したインフラストラクチャやアプリケーションが突如としてこのエラーを吐き始めたなら、それはバグの発生を嘆くべき瞬間ではなく、パーサーがシステムを不正なトラフィックから見事に守り抜いた瞬間かもしれない。
パケットの1バイト、改行コードの1文字に目を凝らすこと。それこそが、真のネットワークアーキテクトとエンジニアを形作る美学なのだ。
コメント