:authority

Host: ヘッダー (HTTP)

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

仕様書

意味

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

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

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

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

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

構文

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

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

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

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

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

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

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

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

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

文脈

[84] Host: ヘッダーHTTP/1.1 仕様書で規定されていますが、 すべての HTTP/1.x に対して定義されています >>83HTTP/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-formasterisk-form が指定されていた場合には、 そこから HTTP/2 要求を生成する場合、 :authority ヘッダーは省略しなければなりません >>18

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

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

処理

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

[401] 以外も同様に Host: を無視するべきでしょうか? (実効要求URLの定義からすると、 もそう解釈するべきでしょう。)
[403] クライアントが不正な操作を試みている可能性もあるので、 要求対象authorityHost: が一致しない場合、起源鯖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] 要求:authorityHost: も含まれない場合や :authority が複数ある場合について RFC には明記されていません。

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

IPv6 アドレス

[82] RFC 6874IPv6アドレスゾーン識別子を添える構文を規定していますが、クライアントプロキシなどは外に出す 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要求URLHTTP と違って絶対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 2732URLauthority を拡張し IPv6アドレスを指定できるように拡張するものでした。 しかし HTTP にどう影響するかは記載されていませんでした。

実装

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

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

関連

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

メモ

[2] この HTTP/1.1 との温度差は、 RTSP/1.0 では要求行URIHTTP とは違って 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]).