摘要

  • 1997 年 1 月的 RFC 2068定义了 HTTP 的 Link 字段，用于描述资源之间的关系，通常把当前请求的资源与另一项资源相连。一个响应实体可以携带多条关系，语义与 HTML 的 LINK 元素相近。
  • 2010 年 10 月的 RFC 5988记载，1999 年 6 月的 RFC 2616因缺乏足够实现经验，删去了这一字段。标准中的空位使它的地位变得含糊，后来一些用户代理仍使用它，新的用途也陆续出现。
  • RFC 5988 以不依附于单一文档格式的类型化链接模型重新定义响应头。2017 年 10 月的 RFC 8288取代它，继续把 HTTP Link 作为表达资源关系的一种方式。

链接跟着响应走

HTML 页面里的链接容易理解：正文或 LINK 元素写出目标，浏览器读完标记后决定怎样处理。可是网络上的资源并非都以 HTML 交付。服务器可能用另一种格式回应同一个地址；若关系只藏在 HTML 正文里，读取其他表示形式的客户端就看不到它。把关系放进 HTTP 响应头，信息便能在解析正文之前到达。

1997 年 1 月公布的 HTTP/1.1 规范 RFC 2068给了这种安排一个名字。第 19.6.2.4 节规定，Link 字段可以描述两项资源之间的关系，通常是当前请求资源与另一项资源的关系。一个实体可带多个值；rel 表示关系类型，title 提供便于人阅读的名称，anchor 则可指定不同的关系起点。文件明确拿 HTML 的 LINK 元素作比较：网页能说的话，HTTP 的响应信封也可以说。

位置改变了可见范围。HTML 标记属于一种具体的表示形式；响应头则和整个 HTTP 回复一起传来。懂这个字段的客户端不用先确认正文是网页，也能读到那条关系。至于是否访问目标、是否显示给用户、怎样解释关系类型，仍由使用它的应用决定。字段给的是一项带类型的连接，不负责取回目标内容。

RFC 2068 把 Link 放在附加功能部分。附近还有名为 LINK 和 UNLINK 的请求方法，分别用于建立和撤销关系。这些方法与响应头是不同机制。后来重写 Link 字段，并不等于那两个请求方法也获得了新生。把它们混成一件事，会让这段历史看起来比原文热闹得多。

1999 年的空位

1999 年 6 月发布的 RFC 2616取代 RFC 2068，却没有保留 Link 字段的定义。原因由后来的 RFC 5988直接说明：当时缺乏足够的实现经验。修订 HTTP/1.1 的作者没有把一项尚未积累充分运行证据的通用机制继续放在基础文本里。

这说的是标准文件怎样取舍，不是一份 1999 年浏览器或服务器普查。要知道哪家产品在哪个版本发送、接收 Link，需要有日期的版本记录和保存下来的响应。原始文件已经足以说明编辑上的赌注：一个想法即使写进上一版规范，也得靠现实运行表现争取下一版的席位。

撤去它又产生了新问题。RFC 5988 回顾说，字段的地位因此不清楚，有些人便考虑为各个应用另造专门的 HTTP 字段。一个原本共有的模式，可能分裂成几套互不相认的名字。真正需要回答的是：资源可以用不同格式呈现时，它该怎样公布自己与另一项资源的关系？

2010 年的文件还记载，撤去之后一些用户代理已经实现 Link，例如用于样式表；其他用途也出现了。这里的措辞是“一些”，不能拿来推算整个浏览器市场。它足以解释为何这件事再次回到标准化桌面：新增的实践与需求让旧问题有了更具体的形状。

回来的链接不再只属于 HTML

2010 年 10 月的 RFC 5988以更新但兼容旧定义的语法重新规定了 Link。更重要的是，它把“链接”抽象成一种不依附单一格式的关系：有上下文资源、关系类型、目标资源，以及可选的目标属性。同一关系可以在 HTML、Atom 或 HTTP 响应头里表达。传输方式不再决定关系本身是什么。

实际需求很清楚。一项资源可以有多种表示形式。若关系只写在某一版 HTML 的正文里，拿到另一种表示的客户端可能完全失去这条线索。响应头可随 HTTP 回复送达，而正文仍按自己的格式组织。HTML 正文里的链接也依旧有价值。规范给各形式一个共同模型，具体应用再规定自己看哪些关系、在哪些地方寻找。

RFC 5988 还扩展了源自 Atom 的关系类型注册表，把 HTML 已有的关系加入更广的名录。一个登记过的关系名解释“这两项资源怎样相连”，不会自动把目标抓取回来，也不能证明目标此刻可访问。浏览器可能重视样式表，归档工具可能重视版本或许可证。它们分享词汇，但各自决定动作。

2017 年 10 月的 RFC 8288取代 RFC 5988，保留“上下文、关系类型、目标、可选属性”的结构。HTTP 的 Link 仍是携带这种结构的一种格式。文件举例区分：网页浏览应用会在 HTML 中寻找 stylesheet，也可能在 HTTP 头中找；Atom 应用则会使用其他关系。关系类型说明资源间的意义，媒体类型说明访问目标后返回什么格式；两者不是同一个问题。

因此，2010 年并非把 1997 年的一段文字原封不动搬回来。最早的字段借了 HTML 链接的形状，让关系能在响应头里出现。后来的两份文件为跨格式的资源关系建立模型和登记机制。回归带着更清楚的边界。

标准等到第二批脚印

若把标准发表当作软件部署，1997、1999、2010 的来回就像任性。分开看便有脉络：1997 年已有足够明确的提案；1999 年还缺足够的实施经验；2010 年已有少量实例与新用途，能支撑一份专门的规范；2017 年模型继续修订。纸上地位由编辑决定，运行中的程序不断改变编辑手里的证据。

争议的实质也不止一个字段名。HTML 里的关系依附于那份表示形式；HTTP 头里的关系可以伴随另一种格式的正文。出版者和客户端因此有一个共同位置来交换带类型的连接，而不用让每项资源都装成网页。

如果要画出详细的采用曲线，还缺有日期的客户端和服务器版本资料，或保存下来的 HTTP 响应。RFC 链条已能证明制度转折：一个曾被写入又因实践不足而移出的字段，在跨格式关系的需求变得具体后，以更完整的模型回到了标准中。