概要
Webmentionは、自分のサイトで他のURLについて言及した際、そのURLに通知を送るためのシンプルな仕組みです。受信側の視点では、他のサイトから自分のURLが言及されたとき、その通知を受け取るためのリクエスト手段となります。
この文書の位置付け
この節は、本書が公開された時点でのその位置付けについて説明します。他の文書が本書に取って代わる場合もあり得ます。現時点での W3C
の公開文書および本技術レポートの最新版については、W3C 技術レポート一覧
この文書は Social Web Working Group により勧告として公開されました。本書についてコメントがある場合は、
public-socialweb@w3.org （購読 、
アーカイブ ）までお送りください。すべてのご意見を歓迎します。
ワーキンググループの 実装レポート もご覧ください。
本文書は W3C のメンバーやソフトウェア開発者、その他 W3C のグループや関係者によってレビューされ、W3C のディレクターにより勧告として承認されています。これは安定した文書であり、参考情報や他の文書からの引用に利用できます。
W3C は仕様の普及と相互運用性の推進のために勧告を作成しています。これによりWebの機能性と相互運用性が向上します。
この文書は
2004年2月5日 W3C 特許ポリシー
の下で作成されました。 W3C はグループ成果物に関連する 特許開示の公開リスト
を管理しています。また、そのページには特許開示の方法も記載されています。何らかの特許情報に関して
必須クレーム を含むと考える場合、その情報は
W3C特許ポリシー第6節
に則り開示しなければなりません。
W3C は、この勧告で規定される機能がFetchの変更によって影響を受けないと予想しています。
本書は
2015年9月1日版 W3C プロセス文書 に準拠し作成されています。
目次
1. はじめに
1.1
Social Web ワーキンググループ1.2
背景1.3 概要1.4
プロトコル概要
2. 適合性
2.1
適合クラス2.2
テストスイートとレポート
3. Webmention
プロトコル
3.1
Webmentionの送信
3.1.1 対象に言及するソース文書の作成3.1.2 送信者が受信者のWebmentionエンドポイントを発見3.1.3 送信者が受信者に通知3.1.4 更新された投稿のWebmention送信3.1.5 削除された投稿のWebmention送信
3.2
Webmentionの受信
3.2.1 リクエストの検証3.2.2 Webmentionの検証3.2.3
エラー応答3.2.4 既存Webmentionの更新
4.
セキュリティに関する考慮事項
4.1
悪用の防止4.2
GETリクエストの制限4.3 localhostへのWebmention送信の回避4.4
クロスサイトリクエストフォージェリ（CSRF）4.5 保護リソースへのアクセス制限4.6
セキュリティとプライバシーのレビュー
5.
その他の考慮事項
5.1 非HTMLコンテンツからのWebmention送信5.2 大規模データセットのWebmention送信5.3 発見時のキャッシュヘッダー尊重
6.
IANAに関する考慮事項A.
フォームエンコードプロパティのURIB. 拡張
B.1 Vouch B.2 Salmention B.3
プライベートWebmention
C. リソース
C.1 記事一覧C.2
実装例
D.
謝辞E. 変更履歴
E.1 2016年11月1日PR からRECへの変更点
F. 参考文献
F.1
標準的な参考文献F.2
参考参考文献
1. はじめに
Webmentionは、あるURLが別のURLにリンクしていることを通知する仕組みです。たとえば、Aliceが自身のブログに興味深い投稿を書きます。Bobが自分のサイトにその投稿への応答を書き、Aliceの元の投稿へリンクします。Bobの公開用ソフトウェアはAliceに対してWebmentionを送り、彼女の記事に返信があったことを通知します。Aliceのソフトウェアは元の投稿にその返信をコメントとして表示できます。
Webmentionの送信はブログ投稿に限らず、さまざまな種類のコンテンツや応答に利用できます。たとえば、応答がイベントへのRSVPであったり、誰かが別の投稿を「いいね」したことの表明であったり、別の投稿の「ブックマーク」であったりすることがあります。Webmentionは異なるウェブサイト間でこれらの相互作用を可能にし、分散型ソーシャルウェブを実現します。
3. Webmention プロトコルこの仕様は、HTMLおよびHTTPのリンク関係のために [HTML5
3.1 Webmention の送信
3.1.1 ターゲットに言及するソース文書を作成する
Webmentionは、ソースURLからターゲットURLへ「言及があった」ことを通知するために送信されます。Webmentionを送信する前に、送信元となるソースURL（多くの場合ブログ投稿だが任意の種類のコンテンツでも良い）が存在している必要があります。
たとえば、https://waterpigs.example/post-by-barnaby のURLは、Aaronの投稿へのリンクを含む次のようなHTMLを含んでいるかもしれません。
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エンドポイントを検出する送信者は MUST ターゲットURLを取得（およびリダイレクトを追跡[FETCH webmention のHTTP Linkヘッダー[RFC5988 <link> および <a>
要素で rel="webmention" を探す必要があります。これらが複数存在する場合は、最初のHTTP Linkヘッダーが優先され、次にドキュメント順で最初の
<link> または <a>
が選ばれます。送信者はこれら3つのオプションすべてをサポートし、この順序でフォールバックすることが MUST です。
エンドポイントは相対URLであり得ます。その場合、送信者は MUST target URL に対して相対解決を行わなければなりません（[URL
エンドポイントはクエリストリングパラメータを含んでいる場合があり、その場合それらはクエリ文字列パラメータとして保持され、Webmentionリクエスト送信時にPOST本文パラメータとして送ってはならない（MUST NOT ）ことに注意してください。
送信者は最初にHTTP HEADリクエスト[RFC7231 MAY ）。
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 >
送信者はターゲットURL取得時に使用するHTTP User
Agentヘッダーをカスタマイズして、受信者に対してこのリクエストがWebmentionディスカバリの一環であることを示してもよい（MAY ）。その場合、User Agent文字列に "Webmention"
を含めることが推奨されます。これにより、なぜディスカバリリクエストが行われたのかを調べたい人への手がかりになります。
3.1.3 送信者が受信者に通知する送信者は MUST
x-www-form-urlencoded [HTML5 source および target パラメータをWebmentionエンドポイントへPOSTしなければなりません。ここで
source はリンクを含む送信者のページのURL、target はリンクされているページのURLです。
WebmentionエンドポイントのURLにクエリ文字列パラメータが含まれている場合、それらのクエリ文字列パラメータは保持され、POST本文として送信してはならない（MUST NOT ）ことに注意してください。
Webmentionエンドポイントはリクエストを検証・処理し、HTTPステータスコードを返します。多くの場合
202 Accepted または 201 Created
が返され、リクエストがキューに入り非同期で処理されていることを示します（DoS攻撃防止のため）。もしレスポンスコードが201であれば、Locationヘッダーにリクエストの状態を監視するためのURLが含まれます。
任意の 2xx レスポンスコードは成功とみなされるべきです（MUST ）。
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を再送信することを SHOULD
推奨します（文書から削除された可能性のあるURLへの再送も含む）。また、URLに新しく現れたリンクに対してもWebmentionを送信することを SHOULD 推奨します。
これにより、Webmentionの受信者はソースドキュメントの表示を更新したり、彼らのURLを言及している投稿が更新されたことを通知したりできます。
投稿が更新された際にWebmentionを送信する場合、送信者は各ターゲットURLのWebmentionエンドポイントを再度ディスカバリすることを MUST 要求します（ターゲットがWebmentionエンドポイントを更新している可能性があるため）。
もしソースURLのページ上にソースへのレスポンスが表示されている（例：コメントとして）なら、送信者はそれをソースURLの更新として扱い、以前に送信したWebmentionを再送信することを SHOULD 推奨します。
3.1.5
削除された投稿に対するWebmentionの送信
ソースURLが削除された場合、送信者はそのURLに対して SHOULD HTTP 410 Gone
ステータスコードを返すべきであり、削除された投稿の「墓碑（tombstone）」表現を表示することを SHOULD
推奨します。通常は投稿内のプロパティの値を空にする、あるいは主要コンテンツ（例：投稿の name や content）を "Deleted"
に置き換えるなどの手法です。送信者はその後、そのドキュメントに対して以前に送信された全てのWebmentionを再送信することを SHOULD 推奨します。
これにより、受信者が以前受け取ったWebmentionをコメント等として表示していた場合、削除をサポートする受信者はそれを表示から除外できます。一方、更新のみをサポートする受信者に対しては合理的なフォールバックを提供します。
3.2 Webmention の受信source および target
パラメータを含むPOSTリクエストを受け取ったら、受信者はパラメータを検証することを SHOULD 推奨します（下記 Request Verification を参照）。その後、DoS攻撃を防ぐためにリクエストをキュー化して非同期に処理することを
SHOULD 推奨します。リクエストへの応答は、受信者の処理方法に応じて3通りあります。
もし受信者が送信者がステータス確認に使えるステータスページを作成する場合、受信者は MUST HTTP 201 Created で応答し、Location
ヘッダーにステータスURLを含めなければなりません。レスポンスボディはコンテンツを含めてもよい（MAY ）。
Example 4
HTTP/1.1 201 Created
Location : http://aaronpk.example/webmention/DEhB9Jme
受信者がリクエストを非同期に処理するがステータスURLを返さない場合、受信者は MUST HTTP 202 Accepted で応答しなければなりません。レスポンスボディはコンテンツを含めてもよく（MAY ）、その場合は人間向けの可読な応答が推奨されます。
Example 5
HTTP/1.1 202 Accepted
受信者が検証ステップを同期的に実行して処理する場合（推奨されない）、成功時には MUST 200 OK で応答しなければなりません。
3.2.1 リクエストの検証受信者は MUST source と
target が有効なURLであること（[URL http
または https を確認することになります）。
受信者は、もしソースURLがターゲットURLと同一である場合、そのリクエストを拒否しなければなりません（MUST ）。
受信者は、target がWebmentionを受け付けられる有効なリソースであるかを同期的にチェックすることを
SHOULD
推奨します。不正なWebmentionを詳細検証の前に拒否するためです。「有効なリソース」の定義は受信者次第です。たとえば、ある受信者は複数ドメインのWebmentionを受け入れるかもしれませんし、別の受信者はエンドポイントと同一ドメイン上のみ受け入れるかもしれません。
ターゲットURLにフラグメント識別子が含まれている場合、受信者がどのURLをWebmention受信対象とするかを制限するならば、チェック時にはそのフラグメントを無視することを SHOULD 推奨します。
3.2.2 Webmention の検証Webmentionの検証は、DoS（サービス拒否）攻撃を防ぐために非同期で処理することを SHOULD 推奨します。
受信者がWebmentionを何らかの方法で利用する場合（投稿上のコメントとして表示する、"like"
カウンタを増やす、投稿者に通知する等）、受信者はソースに対してHTTP GETリクエストを行い、HTTPリダイレクトを追跡して（追跡するリダイレクト数を制限することを SHOULD 推奨）ターゲットを実際に言及していることを確認しなければなりません（MUST ）。受信者は受け入れ可能なコンテンツタイプの優先を示すためにHTTP Acceptヘッダーを含めることを SHOULD 推奨します。
受信者は、メディアタイプごとのルールを使ってソースドキュメントがターゲットURLを言及しているかを判断することを SHOULD 推奨します。たとえば[HTML5 <a href="*">、<img href="*">、<video src="*">
等のリンクを探すべきです。JSON（[RFC7159 target
URLと正確に一致している必要があります（MUST ）。
この時点で、受信者はソースページから取得したコンテンツをターゲットページや他のページに公開してもよく（MAY ）、ソースから取得したその他のデータと併せて表示できます。たとえば、受信者はソースの内容を投稿のコメントとして表示したり、類似のWebmentionを送信した人の一覧に投稿者のプロフィール写真を表示したりすることがあります。
Note
ソースページのコンテンツを再公開する際は、その可視性を意図せず変更してしまわないよう注意が必要です。たとえば、ソースドキュメントが限定的な閲覧者向けに設定されている場合、再公開したコンテンツが一般公開されないように配慮すべきです。ソースドキュメントが認証で制限されているか、受信者が同じファイアウォール内にいるためにしかアクセスできない場合もあります。
3.2.3 エラー応答送信者側の問題によりWebmentionが成功しなかった場合、受信者は MUST 400 Bad Request を返すべきであり、レスポンスボディにエラーの説明を含めてもよい（MAY ）。
GETリクエストをソースに行う前に同期的に返し得る、送信者関連の可能なエラー：
指定された target URL が見つからない。
指定された target URL がWebmentionを受け付けない。
source URL が不正な形式、またはサポートされないスキームである（例：mailto: リンク）
ソースURLの内容を取得した後に発生し得る送信者関連の可能なエラー：
source URL が見つからない。source URL に target URL へのリンクが含まれていない。
Webmentionが受信者サーバー側のエラーにより成功しなかった場合、受信者は SHOULD 500 Internal Server Error を返し、レスポンスボディにエラーの説明を含めてもよい（MAY ）。
3.2.4
既存のWebmentionの更新もし受信者が過去に同じ source と target
の組み合わせでWebmentionを受け取っていた場合、
両方の検証ステップが成功したなら、受信者は既存のWebmentionについてソースから取得したデータを更新することを SHOULD 推奨します。
Webmentionの実装が更新をサポートする場合（いわゆる "Webmention update
implementation"）、受信者はソースの主要オブジェクトのプロパティからのデータ更新をサポートしなければなりません（MUST ）。例：ページの [h-entry
Webmentionの更新実装は、主要オブジェクトの子や他の子孫オブジェクト（例：ページ内のコメントh-entry）からのデータ更新を MAY サポートしてもよいです。注意：これをサポートする実装は、[Salmention
もしソースに対するGETで 410 Gone を受け取った場合、または
200 OK を受け取ったがソース上に target
の言及が見つからなかった場合、受信者は既存のWebmentionを削除するか、削除済みとしてマークすることを SHOULD 推奨します。
Webmentionの処理は冪等であるべきです（SHOULD ）。つまり、同じ source と target
に対してコンテンツに変化がないまま複数回Webmentionを受け取っても、複数の返信として表示されるべきではありません。
4. セキュリティに関する考慮事項
4.1 悪用防止
検証処理はDoS攻撃を防ぐため、3.2節 に従い、キュー化して非同期で処理することが推奨 されます。
受信者は3.2.2節 に従いWebmentionの検証を必須 とします。
受信者がsourceから取得したデータを表示する場合、[XSS CSRF 必須 です。
受信者はWebmentionを公開前にモデレーションしてもよい です。
受信者はWebmentionを定期的に再検証・更新してもよい です。
4.2 GET リクエストの制限
Webmentionプロトコルは、送信者がGET（またはHEAD）リクエストで受信者のエンドポイントを検出し、続いて受信者が送信者のWebページにGETリクエストしてリンクを検証することに依存しています。これは、送信者が受信者に任意のURLへGETリクエストをさせることが可能となり、DoS攻撃のベクトルとなる可能性があります。
受信者はリンク検証時に最初にHTTP HEADリクエストを行ってもよく 、コンテンツタイプや長さ、その他HTTPヘッダーの内容を見てからGETリクエストを行うか判断できます。
受信者はリダイレクト追跡回数に上限を設けるべき です。例えば上限を20回にし、送信元がリダイレクトし続けた場合でもリダイレクトループで詰まらないようにします。
受信者は未検証ソースURLの取得データ量や時間にも上限を設けるべき です。例：ソースURLが5秒以内に応答しなければ失敗とみなす。あるいは最大1MBまで取得し、それ以上は読み込まないようにする（通常HTMLやJSONページはその範囲内）。
4.3 localhost
へのWebmention送信回避
送信者が受信者のWebmentionエンドポイントを検出する際、エンドポイントがlocalhostや他のループバックアドレスである正当な理由はほとんどありません。送信者のlocalhost上に認証のいらないサービスがあると、悪意あるWebmention受信者が任意のPOSTリクエストを自分自身へ送らせるようなエンドポイントを作ることも可能になります。
ディスカバリ時、送信者がエンドポイントがlocalhostまたはループバックIP（127.0.0.0/8）であることを検知した場合、そのエンドポイントへWebmentionを送信すべきではありません 。
4.4 クロスサイトリクエストフォージェリ（CSRF）
この仕様では、Webmentionリクエストに追加のヘッダーやパラメータ（認証ヘッダーやセッションクッキー等）が含まれる場合の特別な扱いを定めていません。ただし、Webmentionエンドポイントが追加ヘッダー付きのリクエストも受け付ける場合、CSRF（クロスサイトリクエストフォージェリ）攻撃への対策を推奨 します。一つの方法として、WebmentionエンドポイントのクエリパラメータにCSRFトークンを含め、送信者がディスカバリ時にそのトークンを取得できるようにするやり方があります。
例えば、ターゲットURLが下記のようなWebmentionエンドポイント（CSRFトークン付き）を示すことができます：
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エンドポイントはリクエスト処理時に最初にこのCSRFトークンの正当性を検証できます。
4.5 保護リソースへのアクセス制限
攻撃者が任意のURLを指すWebmentionエンドポイントを広告することが可能です。そのため、ファイアウォールの内側や、本来なら保護されたリソースにアクセスできるサーバー上にWebmention送信ソフトを設置する際は、攻撃者に内部サーバーへのPOSTリクエストを行わせるリスクがあることに注意してください。これを防ぐため、下記のいずれかの対策を推奨 します：
送信側をそういった内部リソースにアクセスできない環境で動作させる
送信側からの全HTTPリクエストを内部リソースへのアクセスをブロックするプロキシ経由にする
4.6 セキュリティとプライバシーのレビュー以下の質問は「Self-Review Questionnaire: Security and Privacy」([security-privacy-questionnaire
この仕様は個人を特定できる情報を扱いますか？
Webmentionに関わる唯一の個人特定情報は source と target のURLです。
この仕様は高価値データを扱いますか？
いいえ、認証やその他の資格情報は関与しません。
この仕様はoriginに持続的な新しい状態を導入しますか？
いいえ
この仕様はWeb上に持続的なクロスオリジン状態を公開しますか？
Webmention受信者は、Webmentionリクエスト情報をもつ一時的なリソースを作成することがあります。
この仕様は他のオリジンが現在持たないデータへのアクセスを公開しますか？
いいえ
この仕様は新しいスクリプト実行／ロード機構を有効にしますか？
いいえ
この仕様はoriginにユーザ位置情報へのアクセスを許可しますか？
いいえ
この仕様はoriginにユーザ端末のセンサーへのアクセスを許可しますか？
いいえ
この仕様はoriginにユーザ計算環境の側面へのアクセスを許可しますか？
いいえ
この仕様はoriginに他のデバイスへのアクセスを許可しますか？
いいえ
この仕様はoriginにユーザーエージェントのネイティブUI制御を一部許可しますか？
いいえ
この仕様は一時的な識別子をWeb上で公開しますか？
いいえ
この仕様はファーストパーティ・サードパーティ文脈で挙動を区別しますか？
いいえ
ユーザーエージェントの「シークレットモード（プライベート）」ではこの仕様はどう扱うべきですか？
Webmentionは状態を保持しないため、シークレットモードで考慮すべき点はありません。
この仕様はユーザの端末へデータを永続保存しますか？
いいえ
この仕様はデフォルトのセキュリティ特性をダウングレードできますか？
いいえ
5. その他の考慮事項
5.1 非HTMLコンテンツからのWebmention送信もしソースドキュメントがHTMLでない場合（PDF等）、または単純なHTTP
GETリクエストで生のソースを取得できない場合（ペイウォールの背後や同意クリック必須など）、リンク先一覧を記載したHTML形式の「ランディングページ」を用意し、そのURLをWebmention送信時にソースURLとして指定する必要があります。これにより、受信者がリンク検証用に取得可能なURLが得られ、元のソース全体を公開することなくWebmentionを利用できます。
HTMLランディングページを作成することで、学術論文など制限付きコンテンツを参照する場合にも、他の人が参照に使いやすいリンク先を提供できるため、被リンク数を増やす効果もあります。たとえば論文の場合、HTMLページにreference一覧を書いておけば、それぞれをWebmentionターゲットURLに指定できます。
5.2
大規模データセットへのWebmention送信
もしソースドキュメントが特に大きい場合（膨大なHTMLの表や大きなJSONファイルなど）、そのURLでWebmentionを送信するのは避けるべきです。そうしないと、受信者が全データセットをダウンロードして帯域を消費したり、受信者側が帯域削減のため一部のみを取得して検証失敗するリスクもあります。また受信者が自サイトにリンクを再公開したとき、他の閲覧者が誤って全データをダウンロードしてしまう危険も生じます。
ブラウザ表示時に大きなデータをページ分割するのが良い習慣であるように、Webmentionの送信時にも小さなページ単位で送るほうが推奨されます。HTMLなら既存のページ単位URLをそのまま使えます。JSONの場合はページ毎の小さなJSONドキュメントにURLを振って、ソースURLとして使うこともできます。
6. IANAに関する考慮事項以下のリンク関係型は、[RFC5988
Relation Name:
webmention
説明:
WebmentionプロトコルをサポートするターゲットURIを示します。これにより、何らかの公開過程でリソースを言及するクライアントが、そのエンドポイントに連絡して「このリソースが言及された」ことを通知できます。
参照:
W3C
Webmention
Specification (http://www.w3.org/TR/webmention/)備考:
これはRefback, Trackback, Pingbackと同様の「Linkback」機構の一種ですが、異なるプロトコルを使用するため、独自のリンク関係型で発見できるようにする必要があります。
D. 謝辞編集者は、Webmention仕様のオリジナルドラフトを作成してくれたSandeep
Shetty 氏に感謝します。
また、編集者はIndieWeb
コミュニティおよびその他実装者のみなさまのサポート、励まし、情熱にも感謝します。これには（ただしこれらに限らず）Amy Guy、Benjamin Roberts、Ben Werdmüller、Dave
Wilkinson、Rob Sanderson、Tantek Çelik各氏などが含まれます。
↑
1.1 Social Web ワーキンググループ
この節は規範的ではありません。
Webmentionは、Social Web ワーキンググループが作成しているいくつかの関連仕様の一つです。代替アプローチや補完的なプロトコルに興味がある実装者は、まず概要文書[social-web-protocols]を読むことを推奨します。