[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
以降は必須となっています。
[7] HTTP から派生した RTSP は要求URLに HTTP と違って絶対URL
を使っているので、 Host:
ヘッダーはありません >>88。
また SIP も絶対URLを使い、 Host:
ヘッダーはありません。
[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>