摘要

  • PubSubHubbub 想让订阅者不必反复向每个网站询问「有新内容吗」。2010 年草案让发布者通知 hub，再由 hub 抓取更新并推送到订阅者的回调地址。轮询的工作被移到一个分发台。
  • 2018 年 W3C 的 WebSub 推荐标准把分发台的条件写清：202 Accepted 只表示请求已收，回调仍须验证；订阅有期限，订阅者必须在租期结束前续订。开放协议中的每一张订阅票仍要有人按时保管。

不再挨家敲门的读者

旧式订阅阅读器为了拿到新文章，会隔一阵就向网站索取同一个 Feed。大部分请求得到的仍是旧内容。2010 年 2 月的 PubSubHubbub Core 0.3 草案直言轮询令人厌烦，于是安排三方：发布者在 Atom 或 RSS Feed 上标出 hub，内容更新时通知 hub；hub 再抓取 Feed，把变化送往订阅者的回调地址。

这减轻了发布网站门口的排队。发布者通知分发台一次，分发台向多人送件。草案中的参考实现面向 Google App Engine，但起草人明确说任何人都可以运行 hub，协议本身不依附某一家公司的服务器。不过，对某个具体订阅而言，它要经过发布者所公布的那家 hub。开放的是实现资格，承担派送的仍是明确的中间节点。

订阅者提交请求时须提供可从网络访问的回调网址。hub 再向该地址发送 hub.challenge，回调必须原样返回，证明这次订阅确实出自它的意愿。这一步防止别人填上你的地址，替你订阅或退订。hub 同时维护订阅名单、发现 Feed 变化并安排派送。推送减少重复询问，却把排队管理交给了新角色。

收件回执不等于订阅生效

W3C 于 2018 年 1 月宣布 WebSub 成为推荐标准；它是 PubSubHubbub 的新名称。当年的定稿保留发布者、hub 和订阅者三方，把订阅对象扩展为 Web 资源。发布者公布主题与 hub 地址；订阅者发现后向 hub 发送 POST；hub 随后向订阅者回调地址推送内容。

最容易误读的是中途的 HTTP 202 Accepted。标准规定，hub 能处理请求时应回 202，但这只表明收到请求，后面还要核验资格与意愿。hub 可以按自身政策拒绝某个主题或回调网址，也可以在接受后通知拒绝。它必须向回调发送挑战，并检查回传的令牌。一个看似漂亮的 202 回执，只是流程开端，不能拿来证明更新已经开始送达。

租期是第二道门。2010 年草案允许期限，并设想 hub 主动向订阅者复核、自动刷新。2018 年标准要求 hub 执行到期，禁止永久租期；订阅验证时应给出 hub.lease_seconds，订阅者须在期限内重新请求。Feed 仍然公开、发布者仍然更新，错过续订的回调却可能从推送名单中退出。文章没有从网上消失，消失的是到这个地址的定时派送。

标准允许多个 hub，也允许独立实现，但每个被选中的 hub 都要做实事：决定是否接纳主题和回调、验证订阅、计时并分发。发布者向自己指定的 hub 报告更新；两者采用什么通知方式由双方约定。hub 收到通知后取回内容，再 POST 给回调；失败重试有 hub 自己设定的界限。这条链上有好几张不同的收据：发布、通知、受理、验证、租期有效、内容送达。把它们写成一句「实时」会漏掉真正会卡住的环节。