Summary

  • 1996 年 HTTP/1.0 的 Referer 字段让目的服务器知道访客从哪个网址而来，方便统计回链和维护；RFC 当时已提醒，链接来源可能是私人信息。
  • 后来的 W3C Referrer Policy 让页面作者选择发送多少旧网址。strict-origin-when-cross-origin 在安全的跨站请求中只给站点来源，从 HTTPS 前往 HTTP 时不发送该字段。

浏览器走进新网站，口袋里带着一句“我是从这里来的”。1996 年 5 月发布的 HTTP/1.0 RFC 1945 把这句话装进 Referer 请求头。拼错的单词反而在协议里住了下来。服务器用它整理反向链接、看日志、优化缓存、找出写错的链接。站长知道谁在送客；点击链接的人却未必知道，刚离开的页面地址也跟着登门。

1996 年的文件自己就看到了尴尬：链接的来源可能是私密信息，用户应能选择是否发送。手工输入的网址没有来源页，# 后面的片段也不能带过去。可这张名片实在好用。上一页地址越精确，网站越容易追踪来路；同一份精确，也让阅读路线变得清晰。互联网的礼貌介绍，有时像把通讯录一起递给陌生人。

W3C 后来选了一个很具体的例子。一个人在社交网站的个人主页放了喜欢的乐队链接，别人点进乐队网站。乐队知道访客来自哪个社交网站就够了；若连个人主页的完整路径也收到，便可能知道主页属于谁。2017 年 1 月的 W3C Referrer Policy 候选推荐标准 用这个场景说明请求头的分寸：有用的来源信息和多余的私人地址，能塞在同一个信封里。

策略提供了几种封口方法。no-referrer 不递名片；origin 只报协议、主机和端口，把具体路径留在原地。strict-origin-when-cross-origin 在同源请求中可发送去掉敏感组成部分的完整网址；发往另一个安全来源时只发送站点来源；从 HTTPS 去往 HTTP 则保持沉默。最后一条关乎传输：即使只报站名，也可能在未加密的路上被看见。页面作者可以通过响应头等方式表达自己的选择，不必靠每条外链单独讨价还价。

这改变了谁来负责介绍。HTTP 字段给浏览器一种告诉目的站“链接从哪开始”的能力；页面策略让出发页有权决定这句话说多长。社交网站可以告诉乐队“这人从我们这里来”，同时不交出某位用户的主页路径。目的站保留一条统计线索，用户的具体门牌则折在名片里面。

2022 年 6 月的 HTTP 语义规范 RFC 9110 继续沿用那个拼错的 Referer，也继续讲清利与弊。它仍可用于分析、日志和链接维护；网址若包含账户名或保密资源标识，也会暴露刚才的浏览情境。规范去掉片段与用户信息，允许缩短来源网址，并禁止把 HTTPS 页面的来源发进不安全的 HTTP 请求。老名片还在使用，但寄出之前终于可以折叠。

W3C 的 Referrer Policy 发布记录 从 2014 年首份公开草案延续到 2017 年候选推荐标准。它的意义不藏在术语表里，而在每一次点链接时：目的站需要知道来的是哪条街，不必索取每个人的房间号。