WebSub

W3C 勧告

この文書についての詳細
このバージョン:
https://www.w3.org/TR/2026/REC-websub-20260602/
最新公開バージョン:
https://www.w3.org/TR/websub/
最新の編集者草案:
https://w3c.github.io/websub/
履歴:
https://www.w3.org/standards/history/websub/
テストスイート:
https://websub.rocks/
実装報告:
https://websub.net/implementation-reports
編集者:
Julien Genestoux (招待専門家)
Aaron Parecki (招待専門家)
著者:
Julien Genestoux
フィードバック:
public-socialweb@w3.org 件名行を [websub] … メッセージのトピック … としてください（アーカイブ）
正誤表:
正誤表があります。
過去の著者
Brad Fitzpatrick
Brett Slatkin
Martin Atkins
リポジトリ
GitHub
課題
コミット

次も参照してください: 翻訳。

Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

WebSub は、HTTP Web フックに基づいて、あらゆる種類の Web コンテンツの発行者とその 購読者の間で通信するための共通の仕組みを提供します。購読リクエストはハブを介して中継され、ハブはそのリクエストを妥当性検査し、 検証します。その後ハブは、新しいコンテンツや更新されたコンテンツが利用可能になったときに、それを購読者へ配信します。 WebSub は以前 PubSubHubbub として知られていました。

この文書のステータス

この節は、この文書の公開時点での ステータスを説明します。現在の W3C 公開文書と、この技術報告書の最新版の一覧は、 W3C 標準および草案 索引にあります。

この更新された仕様には、クロスサイトスクリプティング（XSS）リスクに関連する緩和策が セキュリティ上の考慮事項の節に追加され、それを報告した人々への謝辞も含まれています。

この文書は、Social Web Working Group によって、 勧告 トラックを用いて勧告として公開されました。

W3C は、Web の標準としてこの仕様が広く 配備されることを推奨します。

W3C 勧告とは、広範な合意形成の後に W3C とそのメンバーによって承認され、 実装のための ロイヤリティフリーのライセンス に対する作業部会メンバーからのコミットメントを有する仕様です。

この文書は、 W3C 特許 ポリシーの下で運営されるグループによって作成されました。 W3C は、 このグループの成果物に関連して行われた あらゆる特許開示の公開リスト を維持しています。そのページには、特許を開示するための 手順も含まれています。ある個人が、 必須クレーム を含むとその個人が考える特許について実際の 知識を有する場合、その情報を W3C 特許ポリシー第6節に従って開示しなければなりません。

この文書は、 2025年8月18日の W3C プロセス文書に準拠します。

1. 定義

トピック
HTTP [RFC7230] （または HTTPS [RFC2818]）リソースURL。変更を購読できる単位。
ハブ （"そのハブ"）
このプロトコルの両側を実装するサーバー（URL [URL]）。どのハブも、誰が利用できるかについて独自のポリシーを実装してMAY。
発行者
トピックの所有者。トピックフィードが更新されたときにハブへ通知する。ほとんどすべての pubsub システムと同様に、発行者は購読者がいるとしてもそれを認識しない。他の pubsub システムでは、 発行者を "ソース" と呼ぶことがある。
購読者
トピック上の変更の通知を受けたいエンティティ（人またはプログラム）。購読者は ネットワークから直接アクセス可能でなければならず、その購読者コールバックURLによって識別される。
購読
そのトピックの更新を受け取るべきであることを示す、購読者によるトピックへの一意な関係。 購読の一意キーは、タプル（トピックURL、購読者コールバックURL）である。購読には（ハブの判断で） DHCP リースに似た有効期限があり、定期的に更新しなければならない場合がある。
購読者 コールバックURL
購読者がコンテンツ配信リクエストを受け取りたい URL [URL]。
イベント
複数のトピックに更新を引き起こすイベント。発生する各イベント（例: "Brad が Linux コミュニティに投稿した。"）について、複数のトピックが影響を受ける可能性がある（例: "Brad が投稿した。" および "Linux コミュニティに新しい投稿がある"）。発行者イベントはトピックを更新させ、ハブは影響を受ける トピックのすべての購読を調べ、コンテンツを購読者へ配信する。
コンテンツ 配信通知 / （コンテンツ 配信リクエスト）
トピックの内容がどのように変更されたか、または更新後の完全な内容を記述するペイロード。トピックの コンテンツタイプによっては、差分（または "デルタ"）がハブによって計算され、すべての 購読者へ送信されることがある。

2. 高水準プロトコルフロー

（この節は非規範的である。）

WebSub フロー 図 購読者 発行者 ハブ 購読者は発行者の ハブ トピックで広告された トピックを発見する 購読者は ハブ へ POST して、トピックの更新を購読する ハブは GET により購読の試行を検証する 発行者は新しいコンテンツを ハブへ通知する ハブは トピックの内容を各購読者へ POST で配信する

このプロトコルの以前のバージョンは PubSubHubbub と呼ばれていた:

3. 適合性

この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、[RFC2119] で説明されているように解釈される。

3.1 適合性

非規範的と記された節に加え、この仕様に含まれるすべての作成ガイドライン、図、例、および注記は 非規範的である。この仕様におけるそれ以外のすべては規範的である。

この文書におけるキーワード MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, および SHOULD NOT は、 ここで示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] で説明されているように解釈される。

3.1.1 適合クラス

WebSub は、発行者、購読者、およびハブという3つの役割を記述する。この節では、各役割の 適合基準を説明する。

3.1.1.1 発行者
  • 適合する発行者は、発見で説明されているように、与えられた リソースURLについてトピックURLおよびハブURLを広告しなければならない（MUST）。
3.1.1.2 購読者

適合する購読者:

  • 発見で説明されているように、指定された順序で各発見メカニズムをサポートして トピックURLおよびハブURLを発見しなければならない（MUST）。
  • 購読者が購読リクエストを送信するで説明されているように、 購読リクエストを送信しなければならない（MUST）。
  • 特定のリース期間を要求してもよい（MAY）
  • 購読リクエストに secret を含めてもよく（MAY）、含める場合は、 コンテンツ配信リクエスト内の署名を検証するために その secret を使用しなければならない（MUST）。
  • コンテンツ配信リクエストに HTTP 2xx ステータスコードで応答しなければならない（MUST）。
  • "unsubscribe" メカニズムを使用して購読を非アクティブ化するよう要求してもよい（MAY）。
3.1.1.3 ハブ

適合するハブ:

  • hub.callback、hub.mode、および hub.topic パラメータを持つ 購読リクエストを受け入れなければならない（MUST）。
  • hub.secret パラメータを持つ購読リクエストを受け入れなければならない（MUST）。
  • 購読リクエストで要求されたリース期間を尊重してもよい（MAY）。
  • すでにアクティブな購読を購読者が再要求することを許可しなければならない（MUST）。
  • 購読解除リクエストをサポートしなければならない（MUST）。
  • トピックURLのコンテンツタイプと一致するコンテンツ配信リクエストを送信しなければならない（MUST）。（コンテンツネゴシエーションを参照）
  • コンテンツ配信で説明されているように、サポートされる形式については コンテンツ配信のペイロードを内容の差分に縮小してもよい（MAY）。
  • 購読が hub.secret で行われた場合、認証済みコンテンツ配信で説明されているように、 X-Hub-Signature ヘッダーを送信しなければならない（MUST）。

3.2 勧告候補の 終了基準

この仕様は、各機能について少なくとも2つの独立した相互運用可能な実装を伴って CR 段階を終了した。 各機能は異なる製品群によって実装されていた可能性がある。すべての機能を単一の製品で実装する という要件はなかった。この基準の目的のために、次の用語を定義する:

3.2.1 発行者

WebSub 発行者とは、1つ以上のリソースURL上でトピックURLおよびハブURLを広告する実装である。 適合基準は上記の適合クラスに記載されている。

3.2.2 購読者

WebSub 購読者とは、与えられたリソースURLからハブURLおよびトピックURLを発見し、 ハブで更新を購読し、ハブからのコンテンツ配信リクエストを受け入れる実装である。 購読者は、認証済みコンテンツ配信をサポートして MAY。適合基準は上記の適合クラスに記載されている。

3.2.3 ハブ

WebSub ハブとは、購読リクエストを処理し、対応するトピックURLが更新されたときに コンテンツを購読者へ配信する実装である。ハブは、secret を伴う購読リクエストを サポートしなければならず（MUST）、要求されたときは認証済みリクエストを配信しなければならない（MUST）。ハブは、リクエスト内でトピックURLの完全な内容を配信しなければならず（MUST）、コンテンツタイプがサポートする場合は、ペイロードを差分に縮小してもよい（MAY）。適合基準は上記の適合クラスに記載されている。

3.2.4 独立

各実装は異なる当事者によって開発されなければならず、別の適格な実装で使用されるコードを 共有、再利用、または派生してはならない。この仕様の実装に関係しないコードの部分は、 この要件から除外される。

3.2.5 相互運用可能

購読者とハブの実装は、ハブが購読者の要求する定義済みの動作を行い、購読者がその機能に従って ハブから期待されるレスポンスを受け取り、ハブが購読者へ期待されるレスポンスを送信する場合、 特定の機能について相互運用可能であると見なされる。

3.2.6 機能

終了基準を評価する目的のため、次のそれぞれが機能と見なされる:

  • リソースURLの HTTP ヘッダーを見ることによって、ハブURLおよびトピックURLを発見する。
  • XML 文書としてリソースURLの内容を見ることによって、ハブURLおよびトピックURLを発見する。
  • HTML 文書としてリソースURLの内容を見ることによって、ハブURLおよびトピックURLを発見する。
  • コールバックURLを用いてハブを購読する。
  • ハブを購読し、特定のリース期間を要求する。
  • secret を用いてハブを購読し、認証済みコンテンツ配信を処理する。
  • unsubscribe リクエストを送信することにより、購読を非アクティブ化するよう要求する。
  • 購読者が妥当性検査リクエスト上の保留中の購読を承認する。
  • 購読者が、無効なトピックURLに対する購読妥当性検査リクエストを拒否する。
  • ペイロードが配信されたときに、購読者が HTTP 2xx レスポンスを返す。
  • 購読者が、認証済みコンテンツ配信リクエストの署名を検証する。
  • 署名が妥当性検証に失敗した場合、購読者が配信リクエストを拒否する。
  • 購読が secret で行われた場合に署名が存在しないとき、購読者が配信リクエストを拒否する。
  • ハブが、購読リクエスト中に要求されたリース期間を尊重する。
  • ハブが、すでにアクティブな購読を購読者が再要求してリース期間を延長することを許可する。
  • ハブが、配信リクエスト内でトピックURLの完全な内容を送信する。
  • ハブが、それをサポートする形式についてトピックURLの差分を送信する。
  • ハブが、secret で行われた購読について有効な署名を送信する。

4. 発見

発見メカニズムは、少なくとも2つのURLを識別することを目的とする。

注記

発行者は、耐障害性および冗長性のために、複数のハブを広告し、それらへ発行したい場合がある。 あるハブが文書への更新を伝播できなかった場合、複数の独立したハブを使用することは、 購読者への配信の可能性を高める方法となる。そのため、購読者は広告されたハブの1つ以上を 購読してよい。

このプロトコルは現在、次の発見メカニズムをサポートする。発行者は、それらの少なくとも1つを 実装しなければならない（MUST）:

注記

<link> は長年にわたり <head> 内に置かれるものに制限されてきたため、一部の利用側コードは <head> だけを検査する可能性がある。したがって、<link> タグは <body> ではなく HTML の <head> 内だけに置くほうが堅牢である。

例 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>

発見を行うとき、購読者は、次の順序で2つすべての発見メカニズムを実装し、 最初に一致したところで停止しなければならない（MUST）:

  1. トピックURLを取得するために GET または HEAD リクエストを発行する。購読者は、 まず HTTP Link ヘッダーを検査しなければならない（MUST）。
  2. HTTP Link ヘッダーが存在せず、かつトピックが XML ベースのフィードまたは HTML ページである場合、 購読者は埋め込みリンク要素を検査しなければならない（MUST）。

4.1 コンテンツネゴシエーション

実用上、rel=self URL が単一の表現だけを提供することが重要である。ハブは、 発見時に購読者がどの Media Type（[RFC6838]）や言語を 要求したかを知る方法がないため、文書の適切な表現を使用してコンテンツを配信できない。

ただし、最初の発見リクエストで使用された HTTP ヘッダーに応じて適切な rel=self URL を返すことにより、コンテンツネゴシエーションを行うことは可能である。 たとえば、application/json を含む Accept ヘッダー付きの /feed へのリクエストは、/feed.json という rel=self 値を 返すことができる。

以下の例は、送信された Accept ヘッダーに応じて、トピックURLが異なる 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: application/json

Link: </feed-de.json>; rel="self"
Link: <https://hub.example.com/>; rel="hub"

{
  "items": [...]
}

5. 購読と購読解除

トピックURLの購読は、直ちに順番に発生する場合も遅延を伴う場合もある4つの部分から成る。

購読解除も同じように機能するが、購読解除の意思を示すために単一のパラメータが変更される。 また、ハブは購読解除リクエストを発行者と共に妥当性検査しない。

5.1 購読者が 購読リクエストを送信する

購読は、購読者がハブURLへ HTTPS または HTTP POST [RFC7231] リクエストを行うことによって開始される。このリクエストは application/x-www-form-urlencoded（[HTML5] の4.10.22.6節で説明） の Content-Type ヘッダーを持たなければならず（MUST）、文書の文字エンコーディングとして UTF-8 [Encoding] を使用しなければならず（MUST）、かつその本文で次のパラメータをそれに応じた形式で使用しなければならない（MUST）:

hub.callback
REQUIRED。コンテンツ配信通知が配信されるべき購読者のコールバックURL。 コールバックURLは、購読ごとに一意な推測困難URLであるべきである（SHOULD）。 （[capability-urls]）
hub.mode
REQUIRED。リクエストの目的に応じて、リテラル文字列 "subscribe" または "unsubscribe"。
hub.topic
REQUIRED。購読者が購読または購読解除したいトピックURL。 これは、発見ステップで見つかった "self" URL でなければならず（MUST）、 発見リクエストを行うために使用されたURLとは異なる場合があることに注意。
hub.lease_seconds
OPTIONAL。購読者が購読をアクティブにしておきたい秒数。 正の10進整数として与えられる。ハブは独自のポリシーに応じて、この値を尊重するかどうかを 選択してよく（MAY）、購読者がこのパラメータを省略した場合に デフォルト値を設定してもよい（MAY）。このパラメータは購読解除リクエストに 存在してもよく（MAY）、その場合、ハブによって無視されなければならない（MUST）。
hub.secret
OPTIONAL。認可済みコンテンツ配信のための HMAC ダイジェストを計算するために使用される、 購読者が提供する暗号学的にランダムな一意の secret 文字列。指定されない場合、 コンテンツ配信リクエストに HMAC ダイジェストは存在しない。このパラメータは、リクエストが HTTPS [RFC2818] 経由で行われた場合にのみ指定されるべきである（SHOULD）。このパラメータは長さが200バイト未満でなければならない（MUST）。

購読者は、ハブによって必要とされる場合、追加の HTTP [RFC7230] リクエストパラメータ、および HTTP [RFC7230] ヘッダーを含めてもよい（MAY）。

ハブは、理解しない追加のリクエストパラメータを無視しなければならない（MUST）。

ハブは、すでに有効化されている購読を購読者が再要求できるようにしなければならない（MUST）。購読または購読解除のためにハブへ行われる後続の各リクエストは、 特定のトピックURLとコールバックURLの組み合わせについて以前の購読状態を上書きしなければならない（MUST）が、それはその動作が検証された後に限られる（4.3節）。 検証に失敗した場合、購読状態は変更されないままにされなければならない（MUST）。これは、購読者がリース秒数の期間が終わる前に、途切れることなく 購読を更新できるようにするために必要である。購読者は、将来の購読で新しい hub.secret 値を 使用してもよく（MAY）、hub.secret なしで新しい購読を行ってもよい（MAY）。

5.1.1 購読パラメータの 詳細

トピックURLおよびコールバックURLは、HTTP [RFC7230] または HTTPS [RFC2818] スキームを使用してよい（MAY）。トピックURLは、発見段階中に Self Link Header で発行者によって 広告されたものでなければならない（MUST）。（3節を参照）。 ハブは、トピックURLが発行者によって広告されたものに対応しない場合、購読を拒否してもよい（MAY）。それ以外の場合、トピックURLは URL 仕様 [URL] に従う自由形式でよい。 ハブは、これらのURLパラメータについて非予約文字を常にデコードしなければならない（MUST）。[URL] の "Percent-encoded bytes" に関する1.2節を参照。

コールバックURLは、推測困難な一意URL（[capability-urls]）であるべきであり（SHOULD）、HTTPS [RFC7230] を使用するべきである（SHOULD）。コールバックURLは、購読を確認し、 コンテンツを配信するときの、ハブから購読者への認証として機能する。さらに、コールバックは 一意であるべきであり（SHOULD）（複数のハブに再利用しない）、 購読が更新されるときに変更されるべきである。

コールバックURLは、任意のクエリ文字列パラメータ（例: ?foo=bar&red=fish）を含んでもよい（MAY）。 ハブは、購読検証中に、&（アンパサンド）文字を使って結合しながら 新しいパラメータをリストの末尾に追加することにより、クエリ文字列を保持しなければならない（MUST）。検証リクエストで使用される名前と重複する名前を持つ既存のパラメータは 上書きされない。コンテンツ配信リクエストを送信するとき、ハブは、POST 本文パラメータとしてではなく、 リクエストのURL部分に任意のクエリ文字列パラメータを含めて、コールバックURLへ POST リクエストを行う。

5.1.2 購読レスポンスの 詳細

ハブURLが WebSub をサポートし、購読または購読解除リクエストを処理できる場合、 リクエストが受信され、これからハブによって検証（5.3節）および妥当性検査（5.2節）されることを示すために、購読リクエストに対して HTTP [RFC7231] 202 "Accepted" レスポンスで応答しなければならない（MUST）。ハブは、 意思の検証および妥当性検査をできるだけ早く実行するべきである（SHOULD）。

ハブが購読リクエスト内に何らかのエラーを見つけた場合、適切な HTTP [RFC7231] エラーレスポンスコード（4xx または 5xx）が返されなければならない（MUST）。 エラーの場合、ハブは、クライアント開発者がエラーを理解するのを支援するために使用される プレーンテキストのエラー説明をレスポンス本文で返すべきである（SHOULD）。 これはエンドユーザーに表示されることを意図していない。ハブは、独自のポリシー（例: ドメイン認可、 トピックURLのポート番号）に基づいて、一部のコールバックURLまたはトピックURLを拒否することを 決定してもよい（MAY）。しかし、意思の検証および妥当性検査は、 HTTP レスポンスが返された後に論理的に開始される非同期ステップであるため、HTTP レスポンスは 検証または妥当性検査のプロセスや結果に依存してはならない（MUST NOT）。

ハブURLが購読または購読解除リクエストを処理できない場合、WebSub をサポートする別のハブへ リダイレクトしてもよい（MAY）。これは、HTTP [RFC7231] 307（一時的リダイレクト）または 308（恒久的リダイレクト）レスポンスを返すことによって行う。 また、購読者が使用するハブの優先URL参照を含む、少なくとも HTTP [RFC7230] Location Header も含めなければならない（MUST）。購読者は、新しいハブURLで 購読または購読解除を再試行することが期待される。

5.2 購読の妥当性検査

購読は、購読を受け入れるか拒否するために詳細を必要とするハブによって妥当性検査されてもよい（MAY）。ハブは、購読を受け入れるべきかどうかを発行者に確認してもよい（MAY）。

購読が受け入れられた場合（およびその時点で）、ハブは購読者の意思の検証を実行しなければならない（MUST）。

購読が拒否された場合（およびその時点で）、ハブは、購読リクエストで与えられた購読者のコールバックURLへ HTTP [RFC7231]（または HTTPS [RFC2818]）GET リクエストを送信することによって、購読者へ通知しなければならない（MUST）。このリクエストには、次のクエリ文字列引数が追加される（[URL] の4節で説明される形式）:

hub.mode
REQUIRED。リテラル文字列 "denied"。
hub.topic
REQUIRED。対応する購読リクエストで与えられたトピックURL。
hub.reason
OPTIONAL。ハブは、購読が拒否された理由を含めてもよい。

購読は、任意の時点で（以前に受け入れられていた場合でも）ハブによって拒否されてもよい（MAY）。その場合、購読者は、その購読がもはや可能ではないと考えるべきである（SHOULD）。

5.3 ハブが 購読者の意思を検証する

攻撃者が購読者の代わりに望ましくない購読を作成する（または望ましい購読を解除する）ことを 防ぐため、ハブは、購読者が確かにその購読リクエストを送信したことを保証しなければならない。

ハブは、購読リクエストで与えられた購読者のコールバックURLへ HTTP [RFC7231]（または HTTPS [RFC2818]）GET リクエストを送信することにより、購読リクエストを検証する。 このリクエストには、次のクエリ文字列引数が追加される（[URL] の4節で説明される形式）:

hub.mode
REQUIRED。リテラル文字列 "subscribe" または "unsubscribe"。これは購読者からハブへの元のリクエストと一致する。
hub.topic
REQUIRED。対応する購読リクエストで与えられたトピックURL。
hub.challenge
REQUIRED。購読を検証するために購読者がエコーバックしなければならない（MUST）、ハブが生成したランダム文字列。このランダム文字列は、 集合 [#x2B] | [#2D-#x39] | [#x3D] | [#41-#x5A] | [#x5F] | [#x61-#x7A] 内の文字だけで構成されなければならない（MUST）。
hub.lease_seconds
REQUIRED/OPTIONAL。購読が期限切れになるまで アクティブなままでいる、ハブが決定した秒数。ハブから購読者へ検証リクエストが行われた時点から測定される。 ハブは、hub.mode が "subscribe" に設定されている場合、このパラメータを 提供しなければならない（MUST）。このパラメータは、hub.mode が "unsubscribe" の場合に存在してもよく（MAY）、その場合、 購読者によって無視されなければならない（MUST）。

5.3.1 検証の詳細

購読者は、hub.topic が、自身が実行したい保留中の購読または購読解除に対応することを 確認しなければならない（MUST）。対応する場合、購読者は hub.challenge パラメータと等しいレスポンス本文を伴う HTTP 成功（2xx）コードで 応答しなければならない（MUST）。購読者がその動作に同意しない場合、 購読者は 404 "Not Found" レスポンスで応答しなければならない（MUST）。

購読者は、反射されたコード注入（反射型XSS）攻撃を防ぐために、購読確認レスポンスに 安全な Media Type を使用しなければならない（MUST）。

ハブは、その他のサーバーレスポンスコード（3xx、4xx、5xx）を、検証リクエストが失敗したことを 意味すると見なさなければならない（MUST）。購読者が HTTP [RFC7231] 成功（2xx）を返したが、コンテンツ本文が hub.challenge パラメータと一致しない場合、 ハブは検証が失敗したとも見なさなければならない（MUST）。

ハブは、hub.lease_seconds を購読者が購読リクエストで渡した値と同じにしてもよい（MAY）が、ハブのポリシーに応じてその値を変更してもよい（MAY）。購読を維持するため、購読者は hub.lease_seconds 秒が 経過する前に、ハブで購読を再要求しなければならない（MUST）。

ハブはリースの期限切れを強制しなければならず（MUST）、 永続的なリース期間を発行してはならない（MUST NOT）。

注記

この仕様は、購読リクエストの確認/拒否とコンテンツの配信とを区別するために GET と POST を 使用する。これは Web アーキテクチャの観点から「ベストプラクティス」とは見なされないが、 コールバックURLの実装をより単純にする。コンテンツ配信リクエストの POST 本文は任意のコンテンツタイプで あり得て、文書の実際の内容のみを含むため、GET と POST の区別を使用してこれら2つのモードの 処理を切り替えることで、実装がより単純になる。

6. 発行

発行者は、トピックが更新されたときに、以前に指定したハブへ通知しなければならない（MUST）。ハブと発行者は、ハブが最終的に更新されたペイロードを 購読者へ送信できる限り、任意のメカニズムについて合意できる。

注記

発行者がハブへ通知するための具体的なメカニズムは未指定のままである。たとえば、 既存の一部の公開ハブ [1] [2] [3] は、発行者に hub.mode="publish" および hub.url=(更新されたリソースのURL) というキーを持つ POST リクエストを 送信するよう求める。

6.1 購読の移行

発行者が既存の購読を新しいトピックURLへ移行したい場合、HTTP リダイレクトを使用してそれを行うことができる。

これは以前のハブ側のいかなる参加も必要とせず、発行者がハブも変更するかどうかに関係なく機能する。

7. コンテンツ配信

トピックURLで新しいコンテンツが利用可能になったとき、コンテンツ配信リクエストはハブから購読者へ 送信される。このリクエストは、ハブから購読者のコールバックURLへの HTTP [RFC7231]（または HTTPS [RFC2818]）POST リクエストである。POST リクエストの HTTP 本文は、 コンテンツ配信通知のペイロードを含まなければならない（MUST）。 コンテンツ配信リクエストは、トピックの Content-Type に対応する Content-Type ヘッダーを持たなければならず（MUST）、以下に説明する例外が許される場合を除き、 トピックURLの完全な内容を含まなければならない（MUST）。

Atom（[RFC4287]）および RSS（[RSS-2.0]）フィードについて、ハブは すでに配信済みの atom:entry または rss:item 要素をフィードから削除してもよい（MAY）。

リクエストは、更新されているトピックに関連付けられたハブを指す rel=hub を持つ Link Header [RFC5988] を 少なくとも1つ含まなければならない（MUST）。また、 更新されているトピックの正準URLに設定された rel=self を持つ Link Header [RFC5988] も1つ含まなければならない（MUST）。ハブは、これらのヘッダーを単一の Link Header [RFC5988] に結合するべきである（SHOULD）。 これらすべてのURLは、発見プロセス（3節）から得られたものである。 購読者は、コンテンツ配信リクエストに対応する購読を識別するために、これらの Link ヘッダーを使用してはならない（MUST NOT）。なぜなら、 Link ヘッダーはトピックコンテンツに関連付けられたメタデータであり、特定の購読に関連付けられたものでは ないからである。たとえば、コンテンツ配信リクエスト内のトピックURLは、 もともと購読されたトピックURLとは異なる場合がある。

購読者のコールバックURLは、成功を示すために HTTP [RFC7231] 2xx レスポンスコードを返さなければならない（MUST）。購読者のコールバックURLは、 購読が削除されたことを示すために HTTP 410 コードを返してもよく（MAY）、 ハブはそのコードをレスポンスとして受け取った場合に購読を終了してもよい（MAY）。 ハブは、その他すべての購読者レスポンスコードを失敗と見なさなければならない（MUST）。 つまり、購読者は購読の移動に HTTP リダイレクトを使用してはならない（MUST NOT）。購読者は、コンテンツ配信リクエストにできるだけ迅速に応答するべきであり（SHOULD）、その成功レスポンスコードは、メッセージの受信のみを示すべきであり（SHOULD）、購読者によって正常に処理されたことの確認を示すべきではない。 購読者からのレスポンス本文は、ハブによって無視されなければならない（MUST）。ハブは、回数および再試行する全体期間について自身が課す制限まで、 コンテンツ配信リクエストを再試行するべきである（SHOULD）。 失敗した配信がハブの制限を超えた場合、ハブはその通知の配信を試みることを停止する。 ハブは、リース期間の終了まで購読をアクティブに保たなければならず（MUST）、 トピックに新しい更新が公開された場合、以前に失敗していた購読者への配信の再試行を 継続しなければならない（MUST）。

7.1 認証済みコンテンツ配信

購読者が購読リクエストで hub.secret の値を提供した場合、ハブは ペイロードの HMAC 署名を生成し、その署名をコンテンツ配信リクエストの リクエストヘッダーに含めなければならない（MUST）。 X-Hub-Signature ヘッダーの値は、 method=signature の形式でなければならず（MUST）、 ここで method は認識されるアルゴリズム名の1つであり、signature は 署名の16進表現である。署名は、リクエスト本文をデータ、hub.secret を鍵として、 HMAC アルゴリズム [RFC6151] を使用して計算されなければならない（MUST）。

7.1.1 認識されるアルゴリズム名

次のアルゴリズムは、公開時点の [FIPS-PUB-180-4] レジストリの内容に基づく、 初期登録済みのアルゴリズム名である。

sha1
[FIPS-PUB-180-4] の6.1節で指定される SHA-1 アルゴリズム
sha256
[FIPS-PUB-180-4] の6.2節で指定される SHA-256 アルゴリズム
sha384
[FIPS-PUB-180-4] の6.5節で指定される SHA-384 アルゴリズム
sha512
[FIPS-PUB-180-4] の6.4節で指定される SHA-512 アルゴリズム

将来、購読者が妥当性検証に使用できるアルゴリズムを示すことを可能にする拡張が 指定される可能性がある。本稿執筆時点では、ほとんどのハブは、SHA-1 に既知の 暗号学的弱点があるにもかかわらず、古い購読者との相互運用性のために SHA-1 で署名している。

7.1.2 署名の妥当性検証

購読者が X-Hub-Signature ヘッダーが指定されたコンテンツ配信リクエストを受け取ったとき、 購読者は、ハブと同じ方法（X-Hub-Signature ヘッダーで提供される）を使用して、 共有 secret により署名を再計算するべきである（SHOULD）。 署名が一致しない場合、購読者はそのメッセージを無効としてローカルに無視しなければならない（MUST）。購読者は、メッセージを非同期に処理できるようにするため、および/または 署名に対するブルートフォース試行を防ぐために、このリクエストを 2xx レスポンスコードで それでも確認してもよい（MAY）。この手法を、購読リクエストにおける HTTPS [RFC2818] とともに使用すると、 単純な購読者は HTTPS [RFC2818] サーバーを実行する必要なく、 ハブから認証済みコンテンツ配信リクエストを受信できる。

ただし、この署名はペイロードが偽造されていないことのみを保証する点に注意してください。 リクエストにはヘッダーも含まれるため、購読者が HTTPS [RFC2818] コールバックを使用している場合を除き、 これらは購読者によって安全であると見なされるべきではない。

8. セキュリティ上の考慮事項

以下はセキュリティ上の考慮事項の要約である。WebSub は HTTP のみに依存する サーバー間プロトコルであることに注意することが重要である。すべてのリクエストに HTTPS を使用することが 強く推奨される。

8.1 発見

購読者がページの <body> 内（および <head> 内）で <link> 要素を探すべきかどうかの判断は単純ではなく、 現在明確な合意はない。発見時に <body> を無視する理由の1つは、 一部の Web サイトが（おそらく偶然に）ユーザーに <link> 要素を含む コンテンツの投稿を許可している可能性があるためである。ただし、作業部会はそのようなサイトの 具体例を把握していない。WebSub 発見がそのような <link> 要素を使用すると、 そのようなサイトに投稿するユーザーは、すべての購読者に代替ハブを使用させ、その後に 悪意のあるコンテンツを配信させる可能性がある。この潜在的な攻撃を考えると、HTML 文書の <head> 内だけで発見を行うことが賢明な場合がある。

8.2 購読

第一に、購読者はハブについて常に HTTPS URL を優先するべきである（その URL が HTTP として広告されている場合でも）（SHOULD）。第二に、購読者は コールバックに一意で推測困難な capability URL を使用し、それらを HTTPS 経由で利用可能にするべきである（SHOULD）。最後に、購読者はコンテンツ配信の署名を可能にするため、 購読時に hub.secret を使用するべきである（SHOULD）。

ハブは短命の hub.lease_seconds を強制するべきである（SHOULD） （10日が適切なデフォルトである）。意思の検証を行うとき、ハブはランダムで単回使用の hub.challenge を使用するべきである（SHOULD）。

意思の検証手順は、反射されたコード注入（反射型XSS）攻撃のリスクをもたらす。 購読者は、この種の攻撃から保護するために、application/octet-stream などの 安全な Media Type を使用して意思の検証レスポンスを提供しなければならない（MUST）。 さらに、意思の検証レスポンスは Content-Security-Policy 制限を 回避するために悪用される可能性があるため、購読者はこれを緩和するために、 X-Content-Type-Options: nosniff を付けて意思の検証レスポンスを 提供しなければならない（MUST）。

意思の検証手順は、信頼された購読者から悪意のあるリソースをダウンロードするようユーザーを だますために使用される可能性がある。購読者は、長さを制限しバイナリデータを拒否するなど、 hub.challenge パラメータに制限を課すべきである（SHOULD）。

8.3 配信

ハブは、購読者が使用した正確なコールバック（HTTPS の使用を含む）を使用しなければならない（MUST）。 ハブは、要求された場合、購読者によって提供された hub.secret を使用して リクエストに署名しなければならない（MUST）。

購読者が購読リクエストに hub.secret を含めた場合、購読者はハブが提供した署名を 検証するべきであり（SHOULD）、検証する場合は、 サーバーが示した署名メカニズムを使用しなければならず（MUST）、検査に失敗したリクエストを破棄しなければならない。

購読者が安全なコールバックURL（HTTPS）を使用しない場合、またはハブと購読者の間の TLS 転送が 侵害されている疑いがある場合、コンテンツ配信通知の完全性は hub.secret と 使用されるハッシュアルゴリズムによってのみ保護される。この場合、アプリケーションの セキュリティ要件に基づいて適切なハッシュアルゴリズムを使用するべきである。この公開日時点で SHA-1 は侵害されていることが実証されているため、少なくとも SHA-256 を使用するべきである。

8.4 セキュリティおよびプライバシーのレビュー

これらの質問は、Self-Review Questionnaire: Security and Privacy（[security-privacy-questionnaire]）に 導かれる、この仕様に関するセキュリティおよびプライバシー上の考慮事項の概要を提供する。

この仕様は個人識別情報を扱うか?
関係する潜在的な個人識別情報は、トピックURLおよびコールバックURLのみである。
この仕様は高価値データを扱うか?
いいえ。認証やその他の資格情報は関係しない。
この仕様は、閲覧セッションをまたいで持続する、オリジンの新しい状態を導入するか?
いいえ。
この仕様は、永続的なクロスオリジン状態を Web に公開するか?
WebSub 購読者は、購読するトピックに関する情報を持つリソースを作成するべきである。
この仕様は、オリジンが現在アクセスできないその他のデータを公開するか?
いいえ。
この仕様は、新しいスクリプト実行/読み込みメカニズムを可能にするか?
いいえ。
この仕様は、オリジンがユーザーの位置情報にアクセスすることを許可するか?
いいえ。
この仕様は、オリジンがユーザーのデバイス上のセンサーにアクセスすることを許可するか?
いいえ。
この仕様は、オリジンがユーザーのローカルコンピューティング環境の側面にアクセスすることを許可するか?
いいえ。
この仕様は、オリジンが他のデバイスにアクセスすることを許可するか?
いいえ。
この仕様は、オリジンがユーザーエージェントのネイティブUIをある程度制御することを許可するか?
いいえ。
この仕様は、一時的な識別子を Web に公開するか?
いいえ。
この仕様は、ファーストパーティおよびサードパーティコンテキストでの振る舞いを区別するか?
いいえ。
この仕様は、ユーザーエージェントの「シークレット」モードの文脈でどのように機能するべきか?
WebSub はサーバー間プロトコルであり、「シークレット」モードに意味はない。
この仕様は、ユーザーのローカルデバイスにデータを永続化するか?
いいえ。
この仕様は、デフォルトのセキュリティ特性の格下げを許可するか?
いいえ。

A. 謝辞

この節は非規範的である。

編集者は、PubSubHubbub の著者、IndieWeb コミュニティ、およびその他の実装者の 支援、励まし、熱意に感謝します。特に編集者は、 Brad Fitzpatrick、 Brett Slatkin、 Martin Atkins、 Amy Guy、 Barry Frost、 Benjamin Roberts、 Eugen Rochko、 Jordan Potter、 Matthias Pfefferle、 Malcolm Blaney、 Marten de Vries、 Sandro Hawke、 Tantek Çelik、 そして Tony Garnock-Jones に感謝します。

W3C チームは、XSS を報告してくれた Gabriel Corona に感謝します

B. 変更履歴

この節は非規範的である。

B.1 2017年10月03日の PR からこのバージョンへの変更

B.2 2017年4月11日の CR から2017年10月03日の PR への変更

B.3 11月24日の WD から2017年4月11日の CR への変更

B.4 10月20日の FPWD から2016年11月24日への変更

C. 参考文献

C.1 規範的参考文献

[capability-urls]
Good Practices for Capability URLs. Jeni Tennison. W3C. 2014年2月18日. FPWD. URL: https://www.w3.org/TR/capability-urls/
[Encoding]
Encoding Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://encoding.spec.whatwg.org/
[FIPS-PUB-180-4]
Secure Hash Standard (SHS). National Institute of Standards and Technology. U.S. Department of Commerce. URL: http://dx.doi.org/10.6028/NIST.FIPS.180-4
[HTML5]
HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 2018年3月27日. W3C 勧告. URL: https://www.w3.org/TR/html5/
[PubSubHubbub-Core-0.3]
PubSubHubbub Core 0.3 -- Working Draft. B. Fitzpatrick; B. Slatkin; M. Atkins. URL: https://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.3.html
[PubSubHubbub-Core-0.4]
PubSubHubbub Core 0.4 -- Working Draft. B. Fitzpatrick; B. Slatkin; M. Atkins; J. Genestoux. URL: https://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC2818]
HTTP Over TLS. E. Rescorla. IETF. 2000年5月. Informational. URL: https://httpwg.org/specs/rfc2818.html
[RFC4287]
The Atom Syndication Format. M. Nottingham, Ed.; R. Sayre, Ed. IETF. 2005年12月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4287
[RFC5988]
Web Linking. M. Nottingham. IETF. 2010年10月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc5988
[RFC6151]
Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. S. Turner; L. Chen. IETF. 2011年3月. Informational. URL: https://www.rfc-editor.org/rfc/rfc6151
[RFC6838]
Media Type Specifications and Registration Procedures. N. Freed; J. Klensin; T. Hansen. IETF. 2013年1月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc6838
[RFC7230]
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed. IETF. 2014年6月. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed. IETF. 2014年6月. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RSS-2.0]
RSS 2.0. Dave Winer. RSS Board. Stable. URL: http://www.rssboard.org/rss-specification
[security-privacy-questionnaire]
Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder; Simone Onofri. W3C. 2025年4月18日. W3C Working Group Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
[URL]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/