摘要

  • 早期 HTTP 请求可以只带路径；TCP 目的地址并不会把用户原先解析的 DNS 名称一并交给 Web 服务器。
  • HTTP/1.1 强制要求 Host，使同一条路径能够归入正确的命名资源空间，也让多个站点共享一个 IP 地址。
  • 绝对形式的 request-target 可能另带一份 authority，因此规范规定优先级、代理改写，并拒绝缺失、重复或无效 Host。

服务器收到地址和一条斜线

RFC 1945 记录了 HTTP/1.0 的常见用法：客户端先解析名称、连接地址，再发送往往只含路径的请求。若一个地址只有一个 Web 站点，GET / 看似完整，因为 TCP 目的地已经隐式选定唯一根目录。

名称共享打破了这个假设。DNS 可以让多个名字指向同一地址，但 Web 服务器不会随 TCP 连接收到客户端刚才问过的 DNS 问题。连接只保留地址和端口，不保留用户点击或输入的标签。同一个 / 因而可能属于多个不同站点。

HTTP/1.1 把 authority 写回消息

1997 年 1 月的 RFC 2068 规定，互联网 HTTP/1.1 请求必须携带 Host。直接访问源站时，请求行通常只放路径与查询，Host 则提供 URI 的网络位置，两者合起来才是确切资源。

规则故意严格：缺少 Host 要返回 400。规范把它列为最重要的变化之一，明确目标是让一个 IP 承载多个网站，并收回那些只为区分 Web 名称而分配的地址。

Host 表达的是客户端意图，不是名称所有权证明。源站仍须验证自己是否为这个 authority 提供服务。

两个名字需要一条优先规则

直连源站常用 origin-form，只含路径。代理收到的 absolute-form 则可能已经含有 scheme、host 与 path。若绝对 URI 说 A、Host 说 B，消息中就出现两个可能目的地。

RFC 2068 让绝对 URI 胜出。RFC 7230 又要求代理忽略收到的 Host，并以 request-target 的 authority 重写它再转发。中间层的职责是把两种表示归一为一个决定，而不是把冲突留给下一跳。

缺失、超过一个或格式无效的 Host 都必须得到 400。若不同组件各自选择第一份、最后一份或最方便的一份，同一请求就可能被代理、缓存和源站送往不同网站。

有效目标是重建结果

RFC 7230 用 effective request URI 描述最终目标。接收者依据本地配置、连接上下文、request-target 形式与 Host 按顺序重建它。路径不是独立资源标识；authority 决定了应在哪个命名空间解释路径。

浏览器声明目标，代理规范化表示，源站验证名称并选择虚拟主机。缓存键、重定向和租户路由必须沿用同一个已经验证的 authority。RFC 7230 特别警告，不能未经核验就用 Host 指向内部服务器或作为共享缓存键。

风险恰恰来自 Host 的实际权力：它会改变应用层去向，却由请求者提供。因此“有这个字段”从来不等于“字段里的名称可信”。

线缆格式改变，单一 authority 不变

RFC 9112 继续要求 HTTP/1.1 只有一份有效 Host；含糊消息不能靠猜测修好。

HTTP/2 主要用 :authority 表达目标。RFC 9113 规定，中间层转成 HTTP/1.1 时必须用它生成 Host，并替换原 Host，除非同时改变请求目标。跨协议转换要保留一个 authority，而不是两份竞争声明。

一个小字段于是解除“一地址一站点”的旧绑定，同时把保持名称唯一、有效与一致的责任交给路径上的每个 HTTP 参与者。

来源与界限

封闭来源集为 RFC 1945、RFC 2068、RFC 7230、RFC 9112 与 RFC 9113。它们证明规则和动机，不证明当前虚拟主机数量、节省的 IP、产品默认值或事件频率。Host 不认证 DNS 所有权、TLS 身份或发送者。