摘要
Webmention 是一种简单的方式，当你在你的网站上提到某个 URL 时，可以通知该 URL。从接收方的角度来看，它是一种请求当其他网站提及它时收到通知的方式。
1. 简介
Webmention 是一种用于通知另一个 URL 被某个 URL 链接所引用的机制。例如，Alice 在她的博客上写了一篇有趣的文章，Bob
随后在他自己的网站上写了一篇回应，并链接回 Alice 的原始帖子。Bob 的发布系统发送一个 Webmention 给 Alice，通知 Alice 她的文章得到了回应，Alice
的系统可将该回应显示为原始文章下的评论。
发送 Webmention 并不局限于博客文章，也可以用于其它类型的内容和回复。例如，回复可以是某个事件的
RSVP、对他人文章的“点赞”、对他人文章的“收藏”等等。Webmention 支持在不同网站之间进行此类互动，实现分布式的社交网络。
3. Webmention 协议
本规范中的 HTML 和 HTTP 链接关系均采用 [HTML5] 定义的 link rel 注册表。
3.1 发送 Webmention
3.1.1 创建提到目标的源文档
Webmention 消息从源 URL 发送到目标 URL，通知目标其被源 URL
所提及。在 Webmention 发送前，必须存在一个“源” URL，通常是博客文章，也可以是其它类型的内容。
例如，https://waterpigs.example/post-by-barnaby 的页面 HTML 可包含如下链接到 Aaron 帖子的内容：
Example 1
<!doctype html>
<html>
<body>
<a href="https://aaronpk.example/post-by-aaron">This is a great post</a>
</body>
</html>
3.1.2 发送方发现接收方 Webmention 端点
发送方必须获取目标 URL（并跟随所有重定向 [FETCH]），并检查 HTTP Link 头 [RFC5988] 是否包含 rel="webmention"。如果文档内容类型为 HTML，则发送方必须查找 rel="webmention" 的 HTML <link> 和
<a> 元素。如三种方式均出现，则优先顺序为第一个 HTTP Link，其次是文档顺序中的第一个 <link> 或
<a>。发送方必须支持所有三种方式并按上述顺序回退。
端点可以是相对
URL，此时发送方必须用 [URL] 规范把该端点补全为相对于目标 URL 的绝对路径。
端点可以含查询参数，这些参数必须保留为查询参数，禁止发送到 POST 请求体内。
发送方可以先发
HTTP HEAD 请求 [RFC7231] 检查 Link 头，再发 GET 请求。
Example 2
GET /post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention-endpoint>; rel="webmention"
<html>
<head>
...
<link href="http://aaronpk.example/webmention-endpoint" rel="webmention" />
...
</head>
<body>
....
<a href="http://aaronpk.example/webmention-endpoint" rel="webmention">webmention</a>
...
</body>
</html>
发送方可以自定义
HTTP User Agent [RFC7231]，在获取目标 URL 时指明此次请求为
Webmention 发现的一部分，推荐在 User Agent 字符串中包含 "Webmention" ，方便对方了解请求来源。
3.1.3 发送方通知接收方
发送方必须向 Webmention 端点发送
x-www-form-urlencoded [HTML5] 表单数据，包含
source 和
target 两个参数。其中 source 为包含链接的发送方页面 URL，target 为被链接的目标页面 URL。
如 Webmention 端点 URL 自身含有查询参数，则这些参数必须保留，并禁止随 POST 请求体发送。
Webmention 端点将校验并处理请求，并返回 HTTP 状态码 [RFC7231]。通常返回 202 Accepted 或
201 Created，表示请求已入队，异步处理，防止 DoS 攻击。如果响应码为 201，Location 头会指明可用于查询请求状态的 URL。
任何 2xx 响应码必须视为请求成功。
Example 3
POST /webmention-endpoint HTTP/1.1
Host: aaronpk.example
Content-Type: application/x-www-form-urlencoded
source=https:
target=https:
HTTP/1.1 202 Accepted
3.1.4 已更新文章的 Webmention
发送
若源 URL 已被修改，发送方推荐重新发送所有已发 Webmention（包括对已移除的链接也重新发送），并对新增链接也推荐发送 Webmention。
这样，Webmention 接收方可更新对源文档的显示，或通知收件人其被提及内容已变动。
当文章更新时重发 Webmention，发送方必须为每个目标 URL 重新发现 Webmention 端点，以防对方已更新端点。
如果源页面上显示了对目标的回复（如作为评论显示），则发送方也应视为源页面变动并推荐重新发送所有已发 Webmention。
3.1.5 已删除文章的 Webmention
发送
若源 URL 被删除，发送方推荐为该 URL 返回 HTTP 410 Gone 状态码，并推荐以“墓碑”方式显示（即所有属性内容清空、或主内容如名称/正文字段改为“Deleted”）。随后，发送方推荐重新发送所有曾为该文档发出的 Webmention。
如此 Webmention 接收端支持删除，则可自动移除已显示过的
Webmention；不支持删除的仍能通过内容变动适当回退。
3.2 接收 Webmention
接收到带 source 和 target 参数的 POST 请求时，接收方推荐校验参数（见下文请求校验），然后推荐将请求异步队列处理，以防止 DoS 攻击。根据处理方式，请求响应有三种可能结果：
接收方若为请求分配了状态页，可供发送方查询，则必须返回 HTTP 201 Created 状态，并在
Location 头中附上该状态 URL。响应体可以带内容。
Example 4
HTTP/1.1 201 Created
Location: http://aaronpk.example/webmention/DEhB9Jme
如果接收方异步处理请求但未返回状态 URL，则必须返回
HTTP 202 Accepted，响应体可以含文本，推荐为人类可读内容。
Example 5
HTTP/1.1 202 Accepted
若接收方选择同步处理并同步校验（不推荐），则请求成功时必须返回
200 OK 状态。
3.2.1 请求校验
接收方必须检查
source、target 是否为有效 URL [URL]，并且协议方案为接收方支持的类型（通常为 http 或 https）。
若 source 和 target 相同，接收方必须拒绝请求。
接收方推荐校验 target
是否为自身可接收 Webmention 的有效资源。此校验推荐同步执行，以便在深入验证前快速拒绝无效请求。“有效资源”含义由实现决定，比如某些可接收多域 Webmention，某些仅限本域。
注意 target URL 可带片段标识符，若接收方限制可接收的 URL，应在校验时忽略片段部分。
3.2.2 Webmention 验证
Webmention 验证推荐异步处理，以防止 DoS
攻击。
如果接收方准备对 Webmention 进一步处理（如将其显示为评论、增加“点赞”计数、通知作者等），其必须对 source 执行 HTTP GET（跟随重定向，建议限制重定向次数），确认页面是否实际包含对 target
的引用。接收方推荐带 Accept 头声明可接受内容类型。
接收方推荐按媒体类型规则判断 source 是否提及
target。例如在 [HTML5] 文档中查找
<a href="*">、<img href="*">、<video src="*">
等链接。JSON ([RFC7159]) 文档则查找属性值全等于 target
的项。纯文本情况下查找字符串匹配。其它类型由实现自定。只有 source 文档内容和 target URL 完全一致时，才视为有效 Webmention。
至此，接收方可以将 source
页内容连同其它采集到的数据发布到目标页或其它页面，例如将 source 内容作为评论显示，或在“点赞者”列表显示作者头像等。
注
二次发布 source
页内容时应注意不要无意间扩大其可见性。例如，若源文档仅向部分用户可见，在转载时应确保不向公众开放。源文档可通过认证或仅允许局域网访问来受限，如果接收方也在同一网络或有权限也需遵守此规则。
3.2.3 错误响应
若 Webmention 请求因发送方自身原因失败，必须返回
400 Bad Request 状态，可可以在响应体内提供错误描述。
同步校验 source 前可返回这些发送方相关错误：
- 指定
target URL 未找到。
- 指定
target URL 不接受 Webmention。
source URL 语法非法或协议不支持（如 mailto:）。
获取 source 内容后可能出现的错误：
source URL 未找到。source URL 未包含对 target 的链接。
如因接收方服务器问题 Webmention 失败，推荐返回
500 Internal Server Error，并可以在响应体内附错误描述。
3.2.4 更新已存在的
Webmention
如果接收方之前收到过相同 source 和 target 的
Webmention，
-
若两步校验都成功，推荐更新当前 Webmention 的 source 数据。
-
若实现支持 Webmention 更新（即“Webmention 更新实现”），则必须支持以
source 主体对象属性为单位的数据更新（如页面的 [h-entry] 属性）。
-
Webmention 更新实现可以支持对子属性（如嵌套 h-entry
评论）的数据更新。建议实现时参考 [Salmention] 扩展。
- 如在第2步（GET source）返回
410 Gone，或为
200 OK 但未找到 target，则推荐删除已有 Webmention
或标记为删除。
- Webmention 处理推荐幂等：即多次收到相同
source 和 target 的
Webmention、内容不变时只算一次回复。
4. 安全性注意事项
4.1 防止滥用
- 为防止 DoS 攻击，验证过程推荐采用排队并异步处理，详见第3.2节。
- 接收端必须按照第3.2.2节校验 Webmention。
- 如果接收端选择展示从 source 获取的数据，必须对数据进行编码和/或过滤，以防止 [XSS] 和
[CSRF] 攻击。
- 接收端可以对 Webmention 进行人工审核后再公开。
- 接收端可以定期复查和更新 Webmention。
4.2 限制 GET 请求
Webmention 协议依赖发送端发起 GET（或 HEAD）请求来发现接收端的 Endpoint，然后接收端又会对发送端的网页发起 GET
请求用于校验链接。这意味着发送端可以导致接收端对任意 URL 发起 GET 请求，存在潜在 DoS 风险。
接收端可以在校验链接时首先发 HTTP HEAD
请求，初步检查内容类型、长度或相关 Header，再决定是否进行完整 GET 请求。
接收端推荐限制HTTP重定向次数，例如最多跟踪20次，以防因发送端连续重定向导致陷入循环。
接收端推荐限制抓取未经验证 source URL
时的数据量和时长。例如 source URL 超过5秒无响应可视为失败，同样可只抓取页面的前1MB内容，一般合理的 HTML 或 JSON 页面不会超过此大小。
4.3 避免发送 Webmention
到本地地址
在发送方发现接收方 Webmention endpoint 时，几乎没有理由将 endpoint 设置为
localhost 或其它 loopback 地址。如果发送方有监听本地服务且未设鉴权，恶意 Webmention 接收端可能构造一个 endpoint 导致发送方对自身本地接口发起任意 POST 请求。
在发现步骤中，如果 endpoint 是 localhost 或回环IP（127.0.0.0/8），发送方不应向其发送 Webmention。
4.4 跨站请求伪造
本规范未对包含额外 Header 或参数（如认证 Header、会话 Cookie）的 Webmention 请求做特殊处理。但如
Webmention endpoint 接受含额外 Header 的请求，应推荐防范 CSRF 攻击。其中一种方式是在
endpoint 的查询参数里加入 CSRF token，使得 Webmention 发送方在发现 endpoint 时一并得到该 token。
例如，目标 URL 可声明一个带 CSRF token 的 Webmention endpoint：
Example 6
GET /post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention?csrf=Q0NTVhYjI0NTVkNDA3M>; rel="webmention"
Webmention endpoint 处理请求时，可先校验 CSRF token 再继续处理其它逻辑。
4.5 限制对受保护资源的访问
攻击者可以声明一个指向任意 URL 的 Webmention
endpoint。所以如果你在防火墙内服务器或有权限访问内部资源的环境中安装 Webmention 发送端软件，需要注意，攻击者可能导致服务器对内网服务器发POST请求。推荐采取措施防止访问受保护资源，可以：
- 让发送端运行在无法访问相关内部资源的环境
- 通过代理转发所有 HTTP 请求，并阻断对内网资源的访问
4.6 安全与隐私评估
下列问题基于自我评估问卷：安全与隐私（[security-privacy-questionnaire]），简要总结本规范涉及的安全与隐私注意事项。
- 本规范是否涉及个人身份信息？
- Webmention 唯一可能涉及个人信息的是源 URL 和目标 URL。
- 本规范是否涉及高价值数据？
- 否，本规范不涉及认证或其它凭据。
- 本规范是否为 origin 引入了可跨会话持久化的新状态？
- 否
- 本规范是否在 web 上暴露了持久性跨域状态？
- Webmention 接收端可能会创建一个临时资源，存储有关 Webmention 请求的信息。
- 本规范是否向某 origin 暴露了其当前不可访问的其它数据？
- 否
- 本规范是否允许新的脚本执行/加载机制？
- 否
- 本规范是否允许 origin 访问用户位置信息？
- 否
- 本规范是否允许 origin 访问用户设备上的传感器？
- 否
- 本规范是否允许 origin 访问用户本地计算环境相关信息？
- 否
- 本规范是否允许 origin 访问其它设备？
- 否
- 本规范是否允许 origin 对用户代理原生 UI 有一定控制？
- 否
- 本规范是否向 web 暴露临时标识符？
- 否
- 本规范是否区分一方/三方场景行为？
- 否
- 本规范在用户代理隐私模式下应如何工作？
- Webmention 不维护任何状态，隐身模式下无特殊考虑。
- 本规范是否将数据写入用户本地设备？
- 否
- 本规范是否允许降低默认安全属性？
- 否
5. 其它注意事项
5.1 从非 HTML 内容发送 Webmention
如果你的源文档不是 HTML（如 PDF），或因受限无法直接用 HTTP GET
请求获取原文（如需付费墙或点击协议），你需建立一个 HTML “落地页”，其中列出所有目标链接。创建好 HTML 落地页后即可用其 URL 作为 Webmention 的 source。这能让接收端有个可抓取
URL 校验对目标的链接，同时避免将完整源文档公开。
制作 HTML
落地页还能提升你的内容被外部引用的频率，为受限内容（如论文）提供一个适合引用的页面。论文类内容建议 HTML 页直接展示参考文献列表，以便用作 Webmention 的 target URL。
5.2 为大数据集发送 Webmention
如果你的源文档规模非常大（如包含上千条记录的大表HTML页，或超大JSON文件），不建议直接用其作为 source
发送 Webmention。这样可能导致接收端下载整个数据集，消耗大量带宽，或者接收端只下载一部分内容而引发校验失败。如果接收端对外转发你的 source 链接，其他访客也可能意外下载完整大数据集。
如网页分页显示数据集是最佳实践，发送 Webmention 时，大数据应仅从较小数据页发起；HTML
可直接用分页后的页面作 source，JSON 则推荐为每页单独设一个较小的 json 文档并用其做 source。
D. 致谢
编辑特别感谢 Sandeep Shetty 对 Webmention 规范原始草案的贡献。
此外，编辑还要感谢 IndieWeb 社区和其他实现者的支持、鼓励和热情，包括但不限于：Amy
Guy、Benjamin Roberts、Ben Werdmüller、Dave
Wilkinson、Rob Sanderson 和 Tantek Çelik。
↑
1.1 社交网络工作组
本节为非规范性内容。
Webmention 是社交网络工作组开发的多个相关规范之一。对替代方案或补充协议感兴趣的实现者应首先阅读概览文档 [social-web-protocols]。