要約

  • 初期HTTPはTCPでaddressへ接続しpathだけを送れたが、serverはclientが解決した元のDNS名を受け取るとは限らなかった。
  • HTTP/1.1はHostを必須にし、同じpathを正しい名前空間へ置くことで、複数siteのIP共有を可能にした。
  • absolute request-targetにもauthorityが入るため、仕様は優先順位、proxyによる置換、欠落・重複・不正値の拒否を定めた。

Addressと「/」だけが届いた

RFC 1945 が記録したHTTP/1.0では、clientはnameを解決し、TCP connectionを開き、しばしばpathだけを要求した。一address一siteならGET /で足りる。接続先が唯一のrootを暗黙に選ぶからである。

複数のnameが同じIPへ向くと、その前提は崩れる。DNS queryはTCP streamに添付されない。Web serverが受け取るのはaddressとportであり、利用者が選んだlabelではない。共有endpointでは同じ/が複数のrootを意味する。

Requestがauthorityを取り戻した

1997年の RFC 2068 はHTTP/1.1 requestにHostを要求した。originへ直接送るrequest-lineは通常pathとqueryだけを持ち、Hostがnetwork locationを補う。正確なresourceは両方から決まる。

Host欠落は400である。仕様はこの変更を、複数Web siteを一IPに置き、名前を区別するためだけのIP allocationを回収する重要条件と説明した。

Hostはclientの意図を示すだけで、ownershipの証明ではない。Originはそのauthorityを自分がserveするか検証しなければならない。

Authorityが二つなら優先順位が要る

直結requestはorigin-formのpathを使う。Proxy向けabsolute-formはscheme、host、pathをすでに含む。そこに異なるHostがあれば、同じmessageに二つの行き先がある。

RFC 2068はabsolute URIを優先した。RFC 7230 はproxyに、受信Hostを無視してrequest-target由来のauthorityへ置換するよう求めた。矛盾を次hopへ移すのではなく、一つに正規化する。

Hostなし、複数Host、不正Hostは400になる。最初か最後かをcomponentごとに選べば、proxy、cache、originが異なるsiteへ同じrequestを送れるからだ。

Effective targetは再構成される

RFC 7230のeffective request URIは、server設定、connection context、request-target、Hostから規則的に作る。Pathだけではresourceは確定せず、どのauthorityの空間で読むかが必要である。

User agentが宣言し、proxyが正規化し、originが検証してvirtual hostを選ぶ。Cache keyとredirectも同じauthorityを使う必要がある。RFC 7230は、未検証Hostを内部redirectやshared cache keyに使う危険を明記した。

Hostが危険なのは飾りだからではない。Requesterが供給する値でありながら、application routingを実際に変えるからである。

Wire表現より長く残った不変条件

RFC 9112 もHTTP/1.1に一つのvalid Hostを要求する。曖昧なtargetを推測で救わない。

HTTP/2では主に:authorityがtarget authorityを表す。RFC 9113 はHTTP/1.1へ変換するintermediaryに、その値からHostを作り、既存Hostを置換するよう定める。Protocol境界を越えても、競合するidentityを二つ残さない。

HostはsiteとIPを分離した。その自由の代価は、経路上の全HTTP actorが同じ名前を一意に保つ責任だった。

情報源と限界

閉じた情報源は RFC 1945、RFC 2068、RFC 7230、RFC 9112、RFC 9113 である。規則と動機は示すが、現在のvirtual host数、節約IP数、product初期値、incident頻度は示さない。HostはDNS control、TLS identity、送信者を認証しない。