摘要
WebSub 提供了一种基于 HTTP web 钩子的通用机制，用于任何类型 Web 内容的发布者与其订阅者之间的通信。订阅请求通过 hub 转发，hub 会对请求进行验证与核查。当有新的或更新的内容可用时，hub
会将其分发给订阅者。WebSub 之前被称为 PubSubHubbub。
本文档状态
本节描述了本文档在发布时的状态。其他文档可能会取代本文件。当前 W3C 发布的文档列表及本技术报告的最新修订版可在
W3C
技术报告索引
本文档由 Social Web 工作组 发布为一份推荐建议。
欢迎对本文档提出意见。所有相关方都可以通过工作组的 问题追踪器 提供实现与漏洞报告及其他意见。这些内容将由 Social Web 社区组 讨论，并在本规范的未来版本中予以考虑。
请参阅工作组的 实现报告 。
本文档经过 W3C 会员、软件开发者以及其他 W3C
组织与相关方的审阅，并已由 W3C 董事确认为 W3C 推荐规范。
本文档内容稳定，可作为参考材料或被其他文档引用。W3C
在制定推荐规范时的作用，是引起对规范的关注并推动其广泛部署。这提升了 Web 的功能性和互操作性。
本文档由
一个遵循
W3C
专利政策W3C 维护着一个关于本组交付物的专利披露公开列表 ；
该页面还包含专利披露的说明。任何已知某专利并认为其包含必要权利要求 的个人，须按照
《W3C 专利政策》第6节 进行披露。
本文件遵循 2017年3月1日 W3C 流程文件 管理。
目录
1. 术语定义2.
协议流程（概述）3. 一致性
3.1
一致性类别3.2 候选推荐退出标准
3.2.1
发布者3.2.2
订阅者3.2.3 Hub3.2.4
独立实现3.2.5
可互操作3.2.6
功能
4. 发现
4.1
内容协商
5.
订阅与取消订阅
5.1 订阅者发送订阅请求
5.1.1 订阅参数详情5.1.2 订阅响应详情
5.2
订阅验证5.3
Hub 验证订阅者意图
5.3.1 验证详情
6. 发布
6.1
订阅迁移
7. 内容分发
7.1
认证内容分发
7.1.1 支持的算法名7.1.2 签名校验
8.
安全性注意事项
8.1
发现8.2
订阅8.3
分发8.4
安全与隐私评估
A.
致谢B. 变更日志
B.1 2017年10月3日PR至本版本的变更B.2 2017年4月11日CR至2017年10月3日PR的变更B.3 2016年11月24日WD至2017年4月11日CR的变更B.4 2016年10月20日FPWD至2016年11月24日的变更
C. 参考文献
C.1
规范性引用C.2
补充性引用
1. 术语定义
主题 (Topic) 一个 HTTP [RFC7230 RFC2818
Hub（“hub”） 实现该协议两端的服务器（URL [URL 可以
实现自己关于可用用户的策略。
发布者 (Publisher) 主题的拥有者。在主题 feed 被更新时通知 hub。和几乎所有的 pubsub 系统一样，发布者并不知道存在的订阅者。其他 pubsub 系统可能称发布者为 “source”。
订阅者 (Subscriber) 希望被通知某主题变更的实体（个人或程序）。订阅者必须可以被直接访问，并由其订阅者回调 URL 标识。
订阅 (Subscription) 订阅者与一个主题的唯一关系，表示应接收该主题的更新。唯一标识为（主题 URL，订阅者回调 URL）二元组。订阅（由 hub 决定）可能有类 DHCP 租期的过期时间，需要周期续订。
订阅者回调 URL 订阅者希望接收到内容分发请求的 URL [URL
事件 (Event) 导致多个主题更新的事件。每次事件发生时（如 “Brad 发帖到 Linux 社区。”），可能影响多个主题（如 “Brad 发帖。”以及 “Linux 社区有新帖子”）。发布者事件更新主题，hub
查找所有受影响主题的订阅并将内容推送给订阅者。
内容分发通知 / （内容分发请求） 描述主题内容变化或者完整内容的有效负载。根据主题内容类型，内容差异（或“增量”）可由 hub 计算并发送给所有订阅者。
2. 协议流程（概述）（本节为非规范性内容。）
订阅者发现主题 URL 的 hub，并向一个或多个公布的 hub 发送 POST 请求，以便在主题发生变化时收到更新。
发布者在其主题发生变化时通知 hub 的 URL。
当 hub 检测到主题变更时，会向所有已注册订阅者发送内容分发通知。
本协议早期版本称为 PubSubHubbub：
4. 发现发现机制旨在找出至少 2 个 URL。
发布者指定的一个或多个 hub 的 URL。如果指定了不止一个 hub URL，期望发布者通知每个 hub，因此订阅者可选订阅其中一个或多个。
订阅者实际用于订阅的规范主题 URL。
注意
发布者可以选择向多个 hub 广播和发布，以实现容错和冗余。如果某一个 hub 未能转发文档更新，采用多个独立 hub 能提升通知订阅者的成功率。因此，订阅者可选择订阅多个公布的 hub。
当前协议支持如下发现机制。发布者 必须 至少实现其中一种：
Link 头信息 [RFC5988 建议 至少包含一个 rel=hub 的 Link 头（hub 链接头）以及一个 rel=self 的
Link 头（self 链接头）。
如果主题是基于 XML 的 feed，发布者 建议 嵌入链接元素，详见 Web Linking [RFC5988 建议 按附录 A 中的方式嵌入 link 元素。
注意
由于 <link> 元素多年限定于 <head> 中，一些代码只会检测
<head> 。因此，将 <link> 标签只放在 HTML <head> 中更为稳妥，不宜放入
<body> 。
示例 1
GET /feed HTTP/1.1
Host : example.com
HTTP/1.1 200 Ok
Content-type : text/html
Link : <https://hub.example.com/>; rel="hub"
Link : <http://example.com/feed>; rel="self"
<!doctype html>
<html >
<head >
<link rel ="hub" href ="https://hub.example.com/" >
<link rel ="self" href ="http://example.com/feed" >
</head >
<body >
...
</body >
</html >
执行发现时，订阅者 必须 依次实现以下三种发现机制，并在首次成功后停止：
对主题 URL 发起 GET 或 HEAD 请求。订阅者 必须 优先检查 HTTP Link 头。
若 HTTP Link 头不存在，且主题为 XML feed 或 HTML 页面，订阅者 必须 检查嵌入的 link 元素。
4.1 内容协商
出于实际目的，rel=self 的 URL 最好只提供单一表现形式。因为 hub 无法获知订阅者请求发现时请求了何种媒体类型（[RFC6838
但可以通过为初始发现请求中的 HTTP 头返回不同的 rel=self URL 来实现内容协商。例如，请求 /feed 时带
Accept 头为 application/json ，可返回 rel=self 值为
/feed.json 。
下例展示了主题 URL 可根据 Accept 头返回不同的 Link 头：
示例 2
GET /feed HTTP/1.1
Host : example.com
Accept : application/json
HTTP/1.1 200 Ok
Content-type : application/json
Link : </feed.json>; rel="self"
Link : <https://hub.example.com/>; rel="hub"
{
"items" : [...]
}
示例 3
GET /feed HTTP/1.1
Host : example.com
Accept : text/html
HTTP/1.1 200 Ok
Content-type : text/html
Link : </feed.html>; rel="self"
Link : <https://hub.example.com/>; rel="hub"
<html >
...
同理，也可根据 Accept-Language 头返回不同的 rel=self URL。
示例 4
GET /feed HTTP/1.1
Host : example.com
Accept-Language : de-DE
HTTP/1.1 200 Ok
Content-type : text/html
Link : </feed-de.json>; rel="self"
Link : <https://hub.example.com/>; rel="hub"
{
"items" : [...]
}
5. 订阅与取消订阅订阅主题 URL 包含四个部分，这些部分可以立刻依次发生，也可以有延迟。
订阅者向 hub 发送订阅请求
hub 验证订阅请求并可选地与发布者验证（可选 ）
hub 确认订阅真正由订阅者发起
hub 定期重新确认订阅仍然有效（可选 ）
取消订阅的步骤相同，只是用单独的参数表示取消操作。此外，Hub 不会向发布者验证取消订阅请求。
5.1 订阅者发送订阅请求订阅由订阅者向 hub URL 发起 HTTPS 或 HTTP POST [RFC7231 必须 使用 application/x-www-form-urlencoded 的
Content-Type 头（详见 4.10.22.6 [HTML5 必须 使用 UTF-8 [Encoding 必须 在请求体中按如下格式包含以下参数：
hub.callback
必需 。订阅者用于接收内容分发通知的回调 URL。回调 URL 应当 为每个订阅唯一、不可猜测的 URL。([capability-urls hub.mode
必需 。字面量字符串 "subscribe" 或 "unsubscribe"，取决于请求的目标。hub.topic
必需 。订阅者希望订阅或取消订阅的主题 URL。注意，这必须 是发现阶段获得的 "self" URL，可能与用于发现的 URL 不同。hub.lease_seconds
可选 。期望订阅保持有效的秒数，为正整数。Hub 可以 根据自身策略决定是否采用该值，也可以 在未指定时设置默认值。该参数可以 存在于取消订阅请求中，此时 hub 必须 忽略该参数。
hub.secret
可选 。订阅者提供的加密随机唯一密钥字符串，用于 认证的内容分发 的 HMAC 签名。如果未提供，内容分发请求不会有 HMAC 签名。该参数应当 只在 HTTPS [RFC2818 必须 小于 200
字节。
订阅者 可以 根据 hub 要求，添加额外的 HTTP [RFC7230
hub 必须 忽略它不理解的额外参数。
hub 必须 允许订阅者重新请求已激活的订阅。每次向 hub 发送的订阅或取消请求必须 在对应主题 URL 与回调 URL 的组合下覆盖之前的订阅状态，但前提是操作已被验证（4.3节 ）。如果验证失败，订阅状态必须 保持不变。这样订阅者可以在租期到期前无缝续订。订阅者可以 在下次订阅时使用新
hub.secret 或不带 secret。
5.1.1 订阅参数详情主题和回调 URL 可以 使用 HTTP [RFC7230 RFC2818 必须 是发布者在自引用 Link 头中公布的 URL（见第3节 ）。Hub 可以 拒绝与发布者声明不符的主题 URL。除此之外，主题 URL 可按 URL 规范自由选择 [URL 必须 始终对这些 URL 参数解码非保留字符，见 [URL “百分号编码字节” 。
回调 URL 建议 为不可猜测的唯一 URL ([capability-urls 建议 使用 HTTPS [RFC7230 建议 唯一（不要多 hub 重复使用）且续订时更换。
回调 URL 可以 带任意查询参数（如 ?foo=bar&red=fish ）。hub 必须 在验证时保留查询串，添加新参数时用 & 连接，且不会覆盖已存在的重名参数。Hub
发送内容分发请求时，会将查询参数包含在 URL 部分（而非 POST body）。
5.1.2 订阅响应详情若 hub URL 支持 WebSub 并能处理订阅或取消请求，则必须 以 HTTP [RFC7231 4.3 节 ）和确认（4.2 节 ）。hub 应尽快 完成验证。
若 hub 检测到订阅请求有误，必须 返回合适的 HTTP [RFC7231 应当 返回纯文本错误描述，便于客户端开发者定位原因（不用于终端用户）。hub 可以 根据自身策略（如域名授权、主题 URL 端口等）拒绝某些回调或主题 URL。但因验证和确认都是异步过程，HTTP 响应禁止 依赖验证或确认的进程或结果。
若 hub URL 无法处理订阅或取消请求，可以 重定向至另一个支持 WebSub 的 hub，可用 HTTP [RFC7231 必须 包含至少一个 HTTP [RFC7230
5.2 订阅验证hub 可以 要求进一步信息以决定是否接受订阅，也可以 与发布者核实是否允许订阅。
当订阅被接受时，hub 必须 对订阅者进行意图验证 。
如果订阅被拒绝，hub 必须 向订阅者回调 URL 发送 HTTP [RFC7231 RFC2818 URL
hub.mode
必需 。字面量字符串 "denied"。hub.topic
必需 。对应订阅请求中的主题 URL。hub.reason
可选 。hub 可附带拒绝原因。
hub 可在任意时间点（即使之前已接受）拒绝订阅。此时订阅者应当 认为无法订阅此主题。
5.3 Hub 验证订阅者意图为防止攻击者替订阅者创建/删除订阅，hub 必须确保订阅请求确实由订阅者本人发送。
hub 会向订阅者回调 URL 发送 HTTP [RFC7231 RFC2818 URL
hub.mode 必需 。字面量字符串 "subscribe " 或
"unsubscribe "，与订阅者原始请求一致。hub.topic 必需 。对应订阅请求中的主题 URL。hub.challenge 必需 。hub 生成的随机字符串，订阅者必须 原样返回以验证订阅。hub.lease_seconds 必需 /可选 。hub
确定的订阅有效秒数，从验证请求发出时开始计。hub 必须 在 hub.mode 为
"subscribe" 时给出此参数，"unsubscribe" 时可以 包含且订阅者必须 忽略。
5.3.1 验证详情订阅者必须 确认 hub.topic 对应其准备执行的待定订阅或取消操作。如是，则必须 以 HTTP 成功（2xx）码响应，且响应体等于
hub.challenge 。如不同意该操作，应必须 以 404 "Not Found" 响应。
hub 必须将服务器端其他响应码（3xx、4xx、5xx）视为验证失败。如订阅者返回 2xx 但响应体与 hub.challenge 不符，也视为失败。
hub 可以 将 hub.lease_seconds
设置为订阅者请求的值，也允许根据自身政策修改。要维持订阅，订阅者必须 在租期之前向 hub 重新请求订阅。
hub 必须 强制租期到期，不得 颁发永久租期。
注意
本规范用 GET 和 POST 区分订阅请求的确认/拒绝和内容分发。虽然这不是 Web 架构层面“最佳实践”，但实现回调 URL 时更简单。由于内容分发请求的 POST body
可能为任意内容类型，仅包含文档内容，故用 GET/POST 区分模式实现上更简便。
6. 发布当主题有更新时，发布者必须 通知此前指定的 hub。hub 与发布者可用任意协议达成一致，只要 hub 最终能将更新内容发送给订阅者。
注意
发布者通知 hub 的具体机制未明确规定。例如，一些公开 hub [1] [2] [3]
要求发布者使用 hub.mode="publish" 和 hub.url=(资源的 URL) 发送 POST 请求。
6.1 订阅迁移如果发布者希望将现有订阅迁移到新的主题 URL，可通过 HTTP 重定向实现。
原主题 URL 应重定向到新主题 URL。这对未用 WebSub、而是直接轮询的 HTTP 客户端可实现无缝过渡。
WebSub 订阅到期后，订阅者会尝试续订，续订第一步会先拉取主题 URL，从而遇到重定向并转到新主题。
在新主题 URL 下，订阅者会看到新的 rel=self URL 和 hub，并在新 hub 订阅新主题。
这不需要原 hub 参与，无论发布者是否切换 hub 均可用。
7. 内容分发当有新内容可用时，Hub 会向订阅者发送内容分发请求。该请求为 Hub 向订阅者回调 URL 的 HTTP [RFC7231 RFC2818 必须 包含内容分发通知负载。内容分发请求必须 有与主题Content-Type 一致的 Header，且必须 包含主题 URL 的全部内容，下述例外情况除外。
对于 Atom ([RFC4287 RSS-2.0 可以 把已经分发的
atom:entry 或 rss:item 元素从 feed 中移除。
请求必须 包含至少一个指向相关 hub 的 rel=hub Link 头 [RFC5988 必须 包含一个
rel=self Link 头，指向当前被更新主题的规范 URL。Hub 建议 将这些合并为一个单独的 Link
头。这些 URL 均源于发现流程（第3节 ）。订阅者不得 用这些 Link
头识别对应的订阅，因为 Link 是内容主题的元数据，而非特定订阅。例如，分发请求中的主题 URL 可能与原始订阅的主题 URL 不同。
订阅者回调 URL 必须 返回 HTTP [RFC7231 可以 用 410 表示订阅已删除，hub 收到后可以 终止订阅。hub 必须 将其它响应码视为失败；即订阅者不得 用 HTTP
重定向进行订阅迁移。订阅者 建议 尽快响应分发请求；其成功码建议 仅表示收到消息，无需确认是否已成功处理。订阅者响应体必须 被 hub 忽略。hub 建议 在次数和时长达到自定义重试上限前持续重试分发。若超过自定阈值，hub 不再发送通知，但仍必须 保持订阅生效至租期结束，且主题有新消息时，必须 继续尝试分发给以前失败的订阅者。
7.1 认证内容分发如果订阅请求中带有 hub.secret ，hub 必须 用该密钥对有效载荷生成 HMAC
签名，并在内容分发请求头中带上该签名。X-Hub-Signature 格式为 method=signature ，其中 method
为算法名，signature 为签名的十六进制字符串。签名必须 采用 HMAC 算法 [RFC6151 hub.secret 为密钥。
7.1.2 签名校验收到带 X-Hub-Signature 的内容分发请求时，订阅者建议 使用同样密钥按算法重算签名。如签名不符，订阅者必须 本地丢弃消息。订阅者可以 以 2xx
响应码确认，以便异步处理消息和/或抵御暴力破解尝试。结合 HTTPS [RFC2818
但须注意该签名仅保证载荷未伪造，头信息是否安全还需订阅者自身按需采用 HTTPS 校验。
8. 安全性注意事项以下是安全注意事项摘要。需强调 WebSub 是纯 HTTP 的服务器到服务器协议，强烈建议所有请求使用 HTTPS。
8.1 发现订阅者是否应在页面 <body> （以及 <head> ）查找 <link> 元素并无定论。忽略
<body> 也是因为部分网站可能让用户上传带 <link>
的内容（虽然目前工作组未见具体案例）。若用于发现，用户可恶意让所有订阅者用替代 hub 推送恶意内容。因此，仅在 HTML <head> 发现更安全。
8.2 订阅首先，订阅者建议 优先选择 hub 的 HTTPS URL（即使是 HTTP 提供）。其次，订阅者建议 为回调用唯一、不可预测的能力型 URL 且用 HTTPS。最后，订阅时建议 附带 hub.secret 便于内容签名。
hub 建议 强制较短的 hub.lease_seconds （10 天较合适）。在验证意图时，hub
建议 使用随机单次 hub.challenge 。
8.3 分发Hub 必须 使用订阅者原回调（含 HTTPS）。如请求带 hub.secret ，Hub 必须 用其签名。
若订阅请求带 hub.secret，订阅者建议 校验签名，且必须 按 server 声明的机制校验，不通过则丢弃请求。
若订阅者不用安全回调（HTTPS），或 hub 与订阅者间 TLS 可能被破坏，则内容通知的完整性仅依赖 hub.secret 和摘要算法。此时应按应用安全需求选用算法。由于 SHA-1 已不安全，建议至少用
SHA-256。
8.4 安全与隐私评估下列问题基于《安全与隐私自评问卷》([security-privacy-questionnaire
本规范是否涉及可识别个人身份的信息？
唯一有可能的个人可识别信息是主题和回调 URL。
本规范涉及高价值数据吗？
否，无身份认证或凭据。
本规范是否为 origin 引入了可跨浏览会话持久化的新状态？
否。
本规范是否将持久跨域状态暴露到 web？
WebSub 订阅者应为每个订阅主题创建一个资源。
本规范是否向 origin 暴露了其当前无法获取的数据？
否。
本规范是否启用新的脚本执行/加载方式？
否。
本规范是否允许 origin 访问用户位置？
否。
本规范是否允许 origin 访问用户设备的传感器？
否。
本规范是否允许 origin 访问用户计算环境的细节？
否。
本规范是否允许 origin 访问其他设备？
否。
本规范是否允许 origin 控制用户代理的本地界面？
否。
本规范是否向 web 暴露临时标识符？
否。
本规范是否区分第一方与第三方环境下的行为？
否。
本规范在用户代理“隐身模式”下如何工作？
WebSub 为服务器间协议，“隐身模式”无意义。
本规范是否会将数据持久化到本地设备？
否。
本规范是否允许降级默认的安全特性？
否。
↑
