摘要

  • 1996 年 5 月的 RFC 1945 允许 Referer 请求头把链接所在页面的 URI 告诉目的服务器。文档列出反向链接清单、日志、缓存和修复旧链接等用途，并在同一节提醒：来源地址可能暴露私人文档。
  • 1997 年 1 月的 RFC 2068 保留该字段，还明说 Referer 拼错了英语单词。用户手动输入的网址没有来源页面可报；字段值不能带 URL 片段。安全章节进一步指出，即使拿掉个人姓名，私人文档的 URI 仍可能泄露。
  • 2017 年 1 月 26 日的 W3C 候选规范把披露程度交给 Referrer-Policy：可以发送完整 URL、只发送网站来源，或完全不发送。它记录的是当时的规则设计，而非各浏览器的部署数量。

收件人为什么想知道寄件地址

1996 年 5 月发布的 HTTP/1.0 原始规范 RFC 1945给目的服务器一个实用线索：当浏览器跟随某页上的链接，它可以在请求里附上 Referer，写明目标 URI 是从哪一个页面取得的。服务器因此能整理谁在链接自己，记访问日志，优化某些缓存操作，也能找出过期或抄错的网址。标准把这些工作直接写了出来。这不是凭空增加的监测装置，而是一件网络维护工具。

设想一家数字图书馆搬走一份资料，旧地址还散落在别人的书单里。带着来源地址来的请求，让图书馆知道哪一页仍在引用旧链接。它不必拥有那家网站，就能向对方指出问题。对各自独立的网站来说，这样的回访地址很有用：万维网本身没有一个总管负责检查每条链接，目的服务器只好从一次次访问中拼出反向地图。

字段一开始也有边界。RFC 1945 说，若用户直接在键盘输入目标网址，请求没有一个带 URI 的来源页，不能发送 Referer。来源 URI 中的片段也不能放进字段。点击一条链接和手动输入地址是两种不同的到达方式。服务器可以收到前者的来路，不能从后者凭空造出一张上一页的名片。

更关键的是警告写在同一小节。来源页本身可能是私人信息，它的地址也可能暴露一处本来私密的信息源。作者强烈建议让用户选择是否发送 Referer，还举出浏览器在公开与匿名浏览之间切换的例子。1996 年的设计记录同时看到了收益和代价。私人地址泄露不是多年后才有人发现的意外副作用。

拼错的词留下了，风险也留下了

1997 年 1 月的 HTTP/1.1 原始规范 RFC 2068保留了这个字段，并直接说明 Referer 是“referrer”的错误拼写。网上交换的字段名没有因此改掉。它仍让目的服务器生成反向链接列表、做日志、追查坏链接。对于手动输入的地址，仍不能发送假想的来源；对于 URL 片段，仍要排除。

错别字容易成为段子，真正改变权力位置的是请求方向：浏览器向目的地送去的消息，夹带着另一处页面的地址。目的站点当然想修好自己的链接，也想知道读者从哪里来。它是否需要看见来源站内部的精确路径，是另一回事。一家机构发来的读者和那家机构某个具体成员的个人页面，并不是同一粒度的信息。

RFC 2068 的安全部分把问题说得更清楚。Referer可以用于研究阅读路线和绘制反向链接；即便剔除了与个人直接相关的内容，它仍可能指出私人文档的 URI。一个个人资料路径、内部工作区名字或会话参数，都可能让 URL 自己泄露上下文。泄露发生在 HTTP 请求头里，链接的可见文字未必露出半点线索。

这两份 RFC 记录的是字段规则和边界，不是当年每款浏览器实际发送了多少完整地址的统计。它们足够证明冲突早已存在：收件服务器要的是一张可修复网络的来路收据，离开页面的人可能不愿意把私人房间的门牌一并写上去。

网站名与房间号之间

完整 URL 不只有域名。路径可能是某个人的资料页、某个工作组的文档，查询参数可能装着会话凭证。浏览器把这一串地址当作 Referer 发给另一个服务器时，目的地知道的便不只是“读者来自某网站”，而是“读者刚刚离开该网站的哪一间房”。读者点击的也许只是一篇文章、一张图或一本书；额外的背景信息藏在请求元数据里。

接收方可以把字段存进日志。只有来源网站熟悉自己的 URL 结构，知道哪些路径指向个人空间，哪些参数不宜外传。读者想看下一个页面，未必想把上一个页面的全部地址交出去。1996 年提到的浏览器开关把决定交给个人，方式较粗。页面级策略则可以按来源文档的性质设定披露程度。

其中的选择不能混为一谈。完整 URL 能帮助目的地定位具体坏链接；只发“来源”即协议、主机和端口，仍能告诉对方流量来自哪家网站，却不复制内部路径与查询参数；完全不发则连网站名也不提供。目的服务器的维护信息越细，来源页交出的信息也越多。

来源页面握住调节钮

W3C 于 2017 年 1 月 26 日发布的 Referrer Policy 候选规范用了一个具体例子：社交网站的个人页面链接到乐队网站。乐队可以知道访问来自社交网站，却未必需要知道哪位用户的资料页提供了链接。文档还举出 URL 携带会话标识或访问能力的应用。此时地址本身就像一张钥匙，或者至少像一个指向钥匙的标签。

草案给出多档规则。no-referrer 不发送该字段；same-origin 允许同一来源内传完整 URL，跨网站则沉默；origin 只给协议、主机、端口，不给路径与参数；strict-origin 对从受保护环境走向不可信目标又加一道限制。另有不同选项分别处理站内与站外请求。问题不再只是“发送还是不发送”，而是“给谁看哪一段地址”。

网站作者可以通过响应头 Referrer-Policy、文档中的 meta 元素、部分元素上的属性，或链接的 noreferrer 关系表达选择。新政策的英文拼写正确；它控制的旧请求头依然叫 Referer。网络没有为了纠正一个字母而要求所有客户端和服务器改口。历史留下的错字，成了两代控制方式并排存在的标记。

2017 年的文本是一份当时的候选规范。它详细规定不同选项在协议上的含义。要给各浏览器的实际启用日期排序，还需要带日期的实现记录。规范已经足以说明设计焦点的移动：知道页面路径可能敏感的来源方，终于有了办法告诉浏览器只带出适量信息。

有用的反向链接也要付账

目的服务器想知道来路，有正当的维护理由。旧链接要修，引用路径要找，读者从哪里发现内容也值得研究。1996 年的 RFC 把这些好处说得很实在，同时把私人 URI 的风险摆在旁边。当“来路”写的是私人页面，它就不再只是方便维修的一张票据。

后来的策略让来源方在发送前定价。它可以提供网站来源，保留成员资料页的路径；也可以选择沉默。目的站点的反向链接表会损失精度。这种损失正是减少披露所付出的具体成本。维护自己的服务器，并不自动让人拥有每位外来读者刚刚离开的精确门牌。

Referer 的拼写错误很容易记住。更值得记住的是两个问题终于被拆开：要不要告诉目的地是哪一家网站送来了访问？要不要把那家网站内部的具体页面也交出去？一条能修坏链接的来源地址，在指向私人房间时，就成了信息分配的决定。

来源