[86] HTTP/1.0 と HTTP/1.1 の Host: ヘッダーは、対象資源のホストとポートを表します。 HTTP/2 では :authority 疑似ヘッダーとなっています。

仕様書

意味

[89] Host: ヘッダーは、対象URLのホストとポートを表します >>85。 HTTP/1.0 と HTTP/1.1 で使います。

[90] 起源鯖は、同じIPアドレスで複数のホスト名の要求を処理している場合でも、 Host: ヘッダーを使って区別できます >>85。

[15] HTTP では、 Host: ヘッダーはクライアントがアクセスしたい起源鯖のホストを表しています。

[14] SSDP では、 Host: ヘッダーは SSDP で使用するマルチキャストアドレスとポートとなります >>13。

[21] :authority 疑似ヘッダーは、 対象URLの authority 部分を表します >>18。 HTTP/2 で使います。

構文

[91] Host: ヘッダーの値は、 RFC 3986 host、または RFC 3986 host、:、 RFC 3986 port を並べたもの、とされています >>85。

[92] ホストには、ドメイン名だけでなく、IPv4アドレスや IPv6アドレスも指定できます。パーセント符号化も使えます。 空文字列にもできます。[93] ポートは空文字列にもできます。先導0も使えます。[95] authority ではないので、 userinfo は使えません。

[96] 対象URLに authority があれば、 そのうち userinfo と @ 以外の部分と同じ値を Host: で送らなければなりません >>85。

[97] 対象URLに authority がなければ、 Host: は空文字列としなければなりません >>85。

[39] 理論上はそのような URL を対象URLにすることができますが (特にプロキシ)、 実際上あり得るのかどうか不明です。[10] Via: や Warning: でも似た構文が使われていますが、細部が異なります。[11] Forwarded: ヘッダーの host 引数では同じ構文が採用されています。

[12] RFC 6874 は RFC 3986 host を拡張して IPv6 ゾーン識別子に対応させていますが、 RFC 6874 も RFC 723x も HTTP Host: における取り扱いは規定していません。

[23] :authority ヘッダーの値は、 URL の authority です。ただし、 userinfo は含んではなりません >>18。 つまりホストでなければなりません。

  1. ホスト名
  2. ?
    1. :
    2. ポート

[31] 約束要求の :authority 疑似ヘッダーの値は、 当該サーバーが authoritative である値でなければなりません >>30。

サーバープッシュ、HTTP接続も参照。

文脈

[84] Host: ヘッダーは HTTP/1.1 仕様書で規定されていますが、 すべての HTTP/1.x に対して定義されています >>83。 HTTP/1.1 に適合するかに関わらず、すべての HTTP/1.x の実装は Host: ヘッダーを実装するべきです >>83。

[402] 現在の鯖の状況を考えると、 HTTP/1.0 要求メッセージであっても、 Host: ヘッダーを送らないとWeb互換とは言えないと思われます。

[94] クライアントは、すべての HTTP/1.1 要求メッセージに Host: ヘッダーを含めなければなりません >>85。

[99] 要求対象が absolute-form であっても、 含めなければなりません。 >>85

[98] クライアントは Host: を最初のヘッダーとするべきです >>85。

[19] この規定にクライアントが実際に従っているのかは謎です。 サーバーはどのみちヘッダーをすべて読まないと処理できないので、 意味のある規定なのかも疑問です。

[22] HTTP/2 では、 :authority ヘッダーを使います。

[25] HTTP/2 要求を直接生成する場合は、 Host: ヘッダーのかわりに :authority 疑似ヘッダーを使うべきです >>18。

[28] Host: ヘッダーを生成することは完全には禁止されていないようですが、 実際のWebブラウザーは生成しないようです。

[24] HTTP/1.1 要求で要求対象に origin-form や asterisk-form が指定されていた場合には、 そこから HTTP/2 要求を生成する場合、 :authority ヘッダーは省略しなければなりません >>18。

[26] HTTP/2 要求を HTTP/1.1 に変換する場合は、 Host: ヘッダーが存在しなければ、 :authority 疑似ヘッダーの値を複製して生成しなければなりません >>18。

[27] HTTP/1.1 の >>405 の規定により、元から存在する場合も値を複製しなければならないと思われます。[29] HTTP/2 では :authority と Host: のどちらかは含まれていなければならないものと思われますが、明確な規定はありません。

処理

[100] 串は、要求対象が absolute-form のとき、 Host: を無視しなければなりません。 >>85

[401] 串以外も同様に Host: を無視するべきでしょうか? (実効要求URLの定義からすると、 鯖もそう解釈するべきでしょう。)[403] クライアントが不正な操作を試みている可能性もあるので、 要求対象の authority と Host: が一致しない場合、起源鯖は 400 を返した方が良いかもしれません。

[405] 串は、メッセージを転送する際は、 absolute-form から新たに Host: を生成しなければなりません。 >>85

[406] 串は転送の際に absolute-form のホストを書き換えることがあります >>404。 (要求対象の項を参照してください。)

[9] 串は Host: を書き換えた際に、元の値を Forwarded: ヘッダーの host 引数に保存できます。

Forwarded: や host を参照。

[101] 鯖は、 HTTP/1.1 要求メッセージに Host: ヘッダーが含まれていないか、 複数含まれているか、 欄値が非妥当であるなら、 400 応答を返さなければなりません。 >>85

[16] Host: ヘッダーの値は、 対象URLや基底文字列URLの計算に使われます。

[17] 実効要求URLのホストの項も参照してください。

[32] :authority 疑似ヘッダーが応答やトレーラー部にあると、 奇形です。

[33] 要求に :authority も Host: も含まれない場合や :authority が複数ある場合について RFC には明記されていません。

[34] :authority が複数あると Chrome は奇形としますが。 Firefox は奇形とはしないようです。

IPv6 アドレス

[82] RFC 6874 はIPv6アドレスにゾーン識別子を添える構文を規定していますが、クライアントやプロキシなどは外に出す URL からゾーン識別子を削除しなければならないとしています。 Host: は URL ではありませんが、これに準じるならゾーン識別子を含めるべきではなさそうです。

代替サービス

[36] 代替サービスを使う場合でも、 Host: に指定する値は元の要求URLのホストです。

代替サービスのホストを示すための Alt-Used: があります。代替サービスも参照。

セキュリティー

[38] 実効要求URL参照。

歴史

[8] Host: は RFC 1945 時代まではありませんでしたが、 バーチャルホストの普及に伴い追加、実装されました。 RFC 2068 による HTTP/1.1 以降は必須となっています。

[87] RFC 2068・2616 (HTTP/1.1)14.23 Host

The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URL URI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the network location naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.

Host 要求頭欄は、利用者又は参照している資源により与えられている元の URI (通常は 3.2.2 節で説明している HTTP URL) から得た要求する資源のインターネット・ホスト及びポート番号を指定します。 Host 欄値は、元の URL で与えられた起源サーバーまたは関門の naming authority を表現しなければなりません。 これによって起源サーバー又は関門は内部的に曖昧な、単一の IP アドレスの複数のホスト名を持つサーバーでの根 / URL のような URL を互いに区別することができます。

  • Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL). For example, a request on the origin server for http://www.w3.org/pub/WWW/ MUST would properly include:

host に尾続のポート情報がないときは、 要求されたサービスの既定ポート (HTTP URL では 80) を暗示します。例えば、 http://www.w3.org/pub/WWW/ の起源サーバーの要求は次のものを適切に含むこととなります。

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

A client MUST include a Host header field in all HTTP/1.1 request messages on the Internet (i.e., on any message corresponding to a request for a URL which includes . If the requested URI does not include an Internet host address name for the service being requested), then the Host header field MUST be given with an empty value. If the Host field is not already present, an An HTTP/1.1 proxy MUST add a Host field to the request message prior to forwarding it on the Internet. ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.

クライアントは、全ての HTTP/1.1 要求メッセージ中に Host 頭欄を含めなければなりません。要求される URI が要求するサービスのインターネット・ホスト名を含んでいない場合は、 Host 頭欄には空の値を与えなければなりません。 HTTP/1.1 串は、その転送するメッセージがその串の要求するサービスを識別する適当な Host 頭欄を含むようにしなければなりません。

See sections 5.2 and 19.5.1 19.6.1.1 for other requirements relating to Host.

派生プロトコル

[7] HTTP から派生した RTSP は要求URLに HTTP と違って絶対URL を使っているので、 Host: ヘッダーはありません >>88。 また SIP も絶対URLを使い、 Host: ヘッダーはありません。

[88] RFC 2326 (RTSP) 12.21 Host

This HTTP request header field is not needed for RTSP. It should be silently ignored if sent.

[1] この HTTP 要求頭欄は RTSP には必要ではありません。 送られても黙って無視するのが良いです。

[81] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.6.3.2

IPv6

[20] RFC 2732 は URL の authority を拡張し IPv6アドレスを指定できるように拡張するものでした。 しかし HTTP にどう影響するかは記載されていませんでした。

実装

[3] NN は、2 で既に Host 頭欄を送ってくれます。 (1 は未確認)

[4] WinIE は、3 未満は送ってくれません。

関連

[5] TLS にも同様の機能である SNI があります。 Host: に対して SNI の普及は遅れていましたが、10年代半ばになってようやく SNI も広く実装されるに至りました。クライアントは、 どちらも指定しなければなりません。

メモ

[2] この HTTP/1.1 との温度差は、 RTSP/1.0 では要求行の URI が HTTP とは違って scheme から始まる完全な絶対URI であるためです。

[6] IP Version 6 Support ( 版) http://msdn2.microsoft.com/en-us/library/aa385325.aspx (名無しさん 2007-02-22 00:31:45 +00:00)

[407] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing ( ( 版)) https://tools.ietf.org/html/rfc7230#appendix-A.1.1

[408] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#page-14

[409] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.6.3.2

[35] Host:リクエストヘッダによるXSS - 葉っぱ日記 ( 版) http://d.hatena.ne.jp/hasegawayosuke/20151110/p1

[37] RFC 3529 - Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) ( 版) https://tools.ietf.org/html/rfc3529

<start number='1' serverName='stateserver.example.com'>

<profile uri='http://iana.org/beep/transient/xmlrpc' />

</start>

The "serverName" attribute is analogous to HTTP's "Host" request-

header field (c.f., Section 14.23 of [3]).