HTTPの「宛先」を読み解く：リクエストターゲットと正規化の深い世界
こんにちは！インフラの現場を渡り歩いているネットワークアーキテクトです。
皆さんは普段、WebブラウザのURL欄にアドレスを入力して「エンター！」と叩くとき、その裏側で何が起きているか考えたことはありますか？実は、Webサーバーという「街の郵便局」には、HTTPというプロトコルを通じて、実にさまざまな形式で「荷物の届け先」が持ち込まれているんです。
今回は、HTTP/1.1のバイブルである「RFC 7231」を紐解きながら、サーバーがどのようにリクエストを受け取り、どうやって迷子にならずに処理しているのか。その「リクエストターゲットの解釈」と「URI正規化」という、地味だけどめちゃくちゃ重要な技術の話をしましょう。
—
1. 郵便配達で例える「リクエストターゲット」の4つの顔
HTTPリクエストの1行目（リクエストライン）、例えば `GET /index.html HTTP/1.1` という文字列。この真ん中の部分が「リクエストターゲット」です。
実はこの書き方、状況によって4つの形式を使い分けています。
① オリジン形式（Origin-form）
`GET /index.html HTTP/1.1`
- 役割: 最も一般的な「普段使い」の形です。
- 例え: 郵便局の窓口で「この街の『中央通り1番地』に届けて！」と言うようなもの。すでに宛先（サーバー）に辿り着いているので、詳細な住所は不要ですよね。
② 絶対URI形式（Absolute-URI-form）
`GET http://www.example.com/index.html HTTP/1.1`
- 役割: プロキシ（中継サーバー）を経由するときに使われます。
- 例え: 「隣町の郵便局へ行く前に、この荷物を中継局に預けるよ。最終的な宛先はここだからね！」と全てを伝える形式です。
③ 権限形式（Authority-form）
`CONNECT www.example.com:443 HTTP/1.1`
- 役割: 主に「トンネル」を作る時に使われます。
- 例え: 「この先、暗号化された中身を運ぶから、まずはこのサーバーへの直通の道を作ってくれ！」という指示ですね。
④ アスタリスク形式（Asterisk-form）
`OPTIONS HTTP/1.1`
- 役割: サーバー全体に対する問い合わせです。
- 例え: 「郵便局さん、あなた自身はどんなサービスに対応しているの？」と、特定の場所ではなく、局そのものに質問するイメージです。
—
2. 隠れた罠！URIの正規化とセキュリティ
さて、ここからが本題です。サーバーに届いた宛先（URI）ですが、実はそのまま鵜呑みにするのは非常に危険です。
例えば、誰かが `GET /images/../secret/config.json` というリクエストを送ってきたらどうでしょう？
`..` は「一つ上の階層へ戻る」という意味ですよね。これを通してしまうと、本来見せてはいけないファイルにアクセスされる「ディレクトリトラバーサル」という攻撃を受けてしまいます。
そこで、サーバーは受け取ったリクエストを「正規化（Normalize）」してから処理を行います。
正規化のステップ（例）
1. パスの解決: `../` を取り除き、正しいパスへ変換する。
2. 大文字小文字の統一: `example.com/File` と `example.com/file` を同じものとして扱うか判定する。
3. エンコードのデコード: `%20` をスペースに戻すなど。
実践：Webサーバー（Nginx等）で考える正規化の重要性
もしあなたがWebサーバーの設定を書くなら、以下のような意識が大切です。
Nginxの例：不正なパスをブロックし、正規化を意識する
location / {
# 1. 冗長なパス（/./ や // など）を解決して整理する
# 2. 不正な文字が含まれていないかチェックする
# 悪意あるアクセスを未然に防ぐための第一歩です
# セキュリティ上のヒント：
# URLのエンコードを悪用した攻撃を避けるため、
# 可能な限り正規化済みのパスでバックエンドへ渡すのが鉄則です
}
—
3. なぜ今、この知識が必要なのか
「フレームワークが勝手にやってくれるから大丈夫でしょ？」と思うかもしれません。確かにWebアプリ開発ではそうです。
しかし、皆さんがインフラエンジニアとして、あるいはトラブルシューティングを行うエンジニアとして現場に立つと、「なぜか特定のURLだけ404になる」「プロキシを通すとパスが壊れる」といった問題に直面します。
その時、この「リクエストターゲットの形式」や「サーバー内部での正規化ルール」を知っていると、解決のスピードが段違いになります。
- パケット解析のとき: 「お、これは絶対URI形式だからプロキシを通ってきているな」と推測できる。
- セキュリティ設定のとき: 「正規化ルールが甘いと、パスをすり抜けて侵入される可能性があるな」と察知できる。
—
最後に：一歩ずつ理解を深めていきましょう！
HTTPの歴史は長く、RFC（技術仕様書）はまるで辞書のように分厚いです。でも、今日お話しした「宛先の書き方の違い」と「それを整理する正規化」という考え方は、ネットワークの仕組みそのものです。
まずは、自分のパソコンからブラウザでアクセスした時、開発者ツールの「ネットワークタブ」を見てみてください。そこに、今日紹介したリクエストラインが隠れています。
「あ、これがオリジン形式だ！」と気づけたとき、Webの世界が少しだけ身近に見えてくるはずですよ。また次の記事でお会いしましょう！
コメント