HTTP リクエストの Host ヘッダフィールドを知ろう

この記事はRFC7230をもとにしています。つまみ食い読みをしているので、間違っていたらすみません。編集リクエストをいただけると幸いです。

HTTP では、クライアントサーバーモデルに基づき、クライアントがサーバーへリソースを要求（リクエスト）し、サーバーはそれに応答（レスポンス）を返します。

クライアントやサーバーが発するものはメッセージと呼ばれます。メッセージは

• 0個以上のヘッダフィールド、
• ヘッダフィールドの終わりを示す空の行、
• オプション（あってもなくてもよい）としてメッセージボディ

からなります。

この記事では HTTP リクエストの特に Host ヘッダフィールドについて理解することを目的とします。

HTTP リクエストメッセージとレスポンスメッセージは、以下のようなものです。（RFC7230 §2.1から引用）

   Client request:

     GET /hello.txt HTTP/1.1
     User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
     Host: www.example.com // ←ここが Hostヘッダフィールド
     Accept-Language: en, mi


   Server response:

     HTTP/1.1 200 OK
     Date: Mon, 27 Jul 2009 12:28:53 GMT
     Server: Apache
     Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
     ETag: "34aa387-d-1568eb00"
     Accept-Ranges: bytes
     Content-Length: 51
     Vary: Accept-Encoding
     Content-Type: text/plain

     Hello World! My payload includes a trailing CRLF.

HTTP リクエストの Host ヘッダフィールドは、アクセスしたい URI とポートの情報をもちます。

Host: www.example.com
もしくは
Host: www.example.com:80

サーバーは単一の IP アドレスについて複数のホストネームを持つことができます。どのホストネームでリソースを要求されたかによって、提供するリソースを振り分ける必要があります。HTTP リクエストを受け取ったサーバーは Host ヘッダを見ることによって、提供すべきリソースを決めることができます。

HTTP リクエストメッセージは必ず Host ヘッダフィールドを含む必要があります (MUST)。

上の例のリクエストメッセージの1行目

GET /hello.txt HTTP/1.1

のことをリクエストラインと呼びます。リクエストラインの GETの直後、この例では /hello.txtの部分をリクエストターゲットと言います。リクエストターゲットはターゲットの URI から作られ、その書き方は4種類あります。

Authority コンポーネント (johndoe@www.example.comみたいなもの、ユーザー名と @はなくてもいいので通常は www.example.comの部分) がターゲット URI に含まれる場合は、 Host ヘッダフィールドにも同じ値 (www.example.com) をもつ必要があります (MUST)。

逆にターゲット URI に authority コンポーネントが欠けている場合は、 Host ヘッダフィールドの値は空でなければなりません (MUST)。¹

Host ヘッダフィールドの値はリクエストを扱うのに重要な情報ですから、ユーザーエージェント（ブラウザとか）はリクエストラインのすぐ直後に Host ヘッダを生成すべきです (SHOULD)。例えば http://www.example.org/pub/WWW/へのリクエストは

     GET /pub/WWW/ HTTP/1.1
     Host: www.example.org

というようになります。

HTTP/1.1 リクエストでは、クライアントはリクエストターゲットを absolute-form (リクエストターゲット参照) で書いた場合であっても Host ヘッダを送らなければなりません (MUST)。Host を実装していない可能性がある古代の HTTP/1.0 プロキシはを経由しても Host 情報が渡されるようにするためです。

プロキシが absolute-form のリクエストターゲットを受け取ったとき、プロキシは Host ヘッダフィールドを無視しリクエストターゲットのホスト情報で置き換えなければなりません (MUST)。そのようなリクエストを転送するプロキシも同様です。

Host ヘッダフィールドはアプリケーションレベルでのルーティング機構として振る舞うため、共有キャッシュポイズニングや意図しないサーバーへのリダイレクトを狙うマルウェアの標的となりがちです。透過プロキシがリクエストを内部サーバーに Host フィールドの値に基づいて振り分けていたり、共有キャッシュのキャッシュキーとして用いられていたりしていて、プロキシを通る通信がそのホストにとって有効な IP をターゲットとしているかの検証をしていない場合には、特に脆弱です。

Host ヘッダフィールドがない、または複数ある、または無効な値になっている HTTP/1.1 リクエストに対してサーバーは 400 Bad Request を返さなければなりません (MUST)。