[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。
[96] 対象URLに authority
があれば、
そのうち userinfo
と @
以外の部分と同じ値を Host:
で送らなければなりません >>85。
[97] 対象URLに authority
がなければ、
Host:
は空文字列としなければなりません >>85。
[12] RFC 6874 は RFC 3986 host
を拡張して IPv6
ゾーン識別子に対応させていますが、 RFC 6874 も RFC 723x
も HTTP Host:
における取り扱いは規定していません。
[23] :authority
ヘッダーの値は、 URL の authority
です。ただし、 userinfo
は含んではなりません >>18。
つまりホストでなければなりません。
[31] 約束要求の :authority
疑似ヘッダーの値は、
当該サーバーが authoritative である値でなければなりません >>30。
[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。
[98] クライアントは Host:
を最初のヘッダーとするべきです
>>85。
[22] HTTP/2 では、 :authority
ヘッダーを使います。
[25] HTTP/2 要求を直接生成する場合は、
Host:
ヘッダーのかわりに
:authority
疑似ヘッダーを使うべきです >>18。
[24] HTTP/1.1 要求で要求対象に origin-form
や
asterisk-form
が指定されていた場合には、
そこから HTTP/2 要求を生成する場合、
:authority
ヘッダーは省略しなければなりません
>>18。
[26] HTTP/2 要求を HTTP/1.1 に変換する場合は、
Host:
ヘッダーが存在しなければ、
:authority
疑似ヘッダーの値を複製して生成しなければなりません >>18。
[100] 串は、要求対象が absolute-form
のとき、 Host:
を無視しなければなりません。
>>85
[405] 串は、メッセージを転送する際は、 absolute-form
から新たに Host:
を生成しなければなりません。
>>85
[9] 串は Host:
を書き換えた際に、元の値を
Forwarded:
ヘッダーの host
引数に保存できます。
Forwarded:
や host
を参照。[101] 鯖は、 HTTP/1.1 要求メッセージに
Host:
ヘッダーが含まれていないか、
複数含まれているか、
欄値が非妥当であるなら、 400
応答を返さなければなりません。 >>85
[16] Host:
ヘッダーの値は、
対象URLや基底文字列URLの計算に使われます。
[32] :authority
疑似ヘッダーが応答やトレーラー部にあると、
奇形です。
[33] 要求に :authority
も Host:
も含まれない場合や :authority
が複数ある場合について
RFC には明記されていません。
[34] :authority
が複数あると Chrome は奇形としますが。
Firefox は奇形とはしないようです。
[82] RFC 6874 はIPv6アドレスにゾーン識別子を添える構文を規定していますが、クライアントやプロキシなどは外に出す
URL からゾーン識別子を削除しなければならないとしています。 Host:
は URL ではありませんが、これに準じるならゾーン識別子を含めるべきではなさそうです。
[36] 代替サービスを使う場合でも、 Host:
に指定する値は元の要求URLのホストです。
[8] Host:
は RFC 1945 時代まではありませんでしたが、
バーチャルホストの普及に伴い追加、実装されました。 RFC 2068 による HTTP/1.1
以降は必須となっています。
The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original
URLURI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent thenetwork locationnaming 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/>
MUSTwould properly include:
host
に尾続のポート情報がないときは、
要求されたサービスの既定ポート (HTTP URL では 80
)
を暗示します。例えば、 <http://www.w3.org/pub/WWW/> の起源サーバーの要求は次のものを適切に含むこととなります。
GET /pub/WWW/ HTTP/1.1 Host: www.w3.orgA 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 hostaddressname 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, anAn HTTP/1.1 proxy MUSTadd 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.119.6.1.1 for other requirements relating to Host.
[7] HTTP から派生した RTSP は要求URLに HTTP と違って絶対URL
を使っているので、 Host:
ヘッダーはありません >>88。
また SIP も絶対URLを使い、 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>
[20] RFC 2732 は URL の authority を拡張し IPv6アドレスを指定できるように拡張するものでした。 しかし HTTP にどう影響するかは記載されていませんでした。
[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>
<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]).