要約

  • PubSubHubbubは、購読者が各サイトへ「新着は？」と何度も問い合わせる仕事を、発行者・ハブ・コールバックの連携に置き換えた。2010年の草案ではハブが更新を取りに行き、購読先へ配る。速さは中継役の仕事に支えられた。
  • 2018年のW3C WebSub勧告では、ハブの 202 Accepted は受付であり、購読成立の証明ではない。コールバック確認と期限付きの購読が続き、期限前の更新手続きは購読者の仕事になった。

更新を聞きに歩く仕事をやめる

フィードを読むサービスは、新しい記事がなくても定期的に各発行元へ取りに行く。大半の返事が前回と同じなら、通信は空振りになる。2010年2月のPubSubHubbub Core 0.3草案は、その反復をやめる案だった。発行者がAtomまたはRSSフィードにハブを示し、更新時にハブへ知らせる。ハブはフィードを取得し、変化を購読者のコールバック先へ配る。

サイトの玄関に各読者が列を作らずに済む。発行者は配送所に知らせ、配送所が多数へ届ける。草案の参照実装はGoogle App Engineを使ったが、草案は誰でもハブを運営できると述べた。方式は一社の専有物ではない。ただし一件の購読は、発行者が示した特定のハブを通る。自由に作れる仕組みと、実際の配送経路は別の話だ。

購読を申し込む側は、外からアクセスできるコールバックURLを渡す。ハブはそのURLに hub.challenge を送り、同じ値を返させて本人の意思を確かめる。第三者が勝手に他人のURLを申し込み、あるいは解除するのを防ぐためだ。ハブは購読の一覧と更新の配送も抱える。繰り返し取得する負担を減らした分、取り次ぎの仕事は一カ所に集まる。

202は窓口の番号札

W3Cは2018年1月、WebSubを勧告として公表した。PubSubHubbubの新しい名前である。2018年版の仕様は発行者・ハブ・購読者の三者を残し、購読対象をフィードだけでなくWebの資源として扱う。発行者が対象とハブを示し、購読者がハブへPOSTし、ハブがコールバックへ内容をPOSTする。

申し込みに対するHTTP 202 Accepted は、成立通知に見えてしまう。仕様での意味は、ハブが要求を受け取り、これから確認に進むということだ。ハブは対象URLやコールバックURLを自分の方針で拒める。受け付けた後もコールバックへ確認用の値を送り、正しく返ってくるまで意思は確定しない。番号札を手にした時点では、まだ配達名簿に載ったとは言えない。

期限にも違いがある。2010年草案は期限を扱い、ハブが購読者に再確認して自動更新する流れを描いた。2018年勧告は期限の執行をハブに義務付け、無期限の購読を認めなかった。確認時にハブが知らせる hub.lease_seconds が切れる前に、購読者自身が再度申し込む。発行元のフィードは更新され続けても、手続きを逃した購読先へのプッシュは途切れうる。

2018年の仕様は複数のハブと独立した実装を許す。一方、発行者が指定したハブは受け入れ、確認、期限管理、内容の配達を担う。発行者からハブへの更新通知方法は当事者間で決める。ハブの失敗配達の再試行にも、ハブ自身の限度がある。「更新された」「ハブが知った」「申請を受けた」「確認した」「期限内」「届けた」は、同じ出来事ではない。