Pingback 1.0

概要

Pingback とは、誰かが web のドキュメントにリンクを張ったとき、そのことをリンク先のサイトに通知するための方法です。典型的な使い方としては、web バブリッシングソフトウェアがユーザに代わって、リンク先のサイトにリンクを張ったことを通知し、リンク先にリンク元のドキュメントへの逆リンクの自動生成を可能にするというものです。

仮にアリスさんが非常におもしろい文章を自分のブログに書いていていて、ボブさんがそれを読み、その感想をアリスさんの文章へのリンクを付けて自分のブログに書いたとします。pingback を使うと、アリスさんの文章へリンクを張ったことをボブさんのソフトウェアが自動的に通知し、アリスさんのソフトウェア側では、どこからリンクが張られているかの情報をサイトに表示することが可能になります。

この文書の状態

これは確定した仕様です。仕様に対する意見は blogite メーリングリスト (アーカイブ)で受け付けています。

今のところ、この仕様書に沿った6つの異なる実装があります。ただし、準拠状態に関する公式なテストはおこなっていません。

• Simon Willison さんの Web log (annoucement)
• Stuart Langridge さんの Web log (announcement)
• Nicholas Avenell さんの Epistula (announcement, source)
• Michel Valdrighi さんの b2 (home page)
• Ian Hickson さんの Web log (source)
• Ian Hickson さんの Pingback Proxies (source)

pingback を実装した人はぜひ http://www.hixie.ch/specs/pingback/pingback に pingback して登録してください。

入手可能な翻訳

英語バージョンがこの仕様の正式バージョンです。翻訳版については http://www.hixie.ch/specs/pingback/translations/ をご覧ください。

目次

• 1. はじめに
  • 1.1. 技術的な詳細
  • 1.2. 用語の定義
• 2. サーバの自動検知
  • 2.1. HTTP ヘッダ
  • 2.2. Link 要素
  • 2.3. 自動検知アルゴリズム
• 3. XML-RPC インターフェース
• 4. 仕様への準拠
• 5. 例
• A. 参考文献

1. はじめに

pingback とは、blog に他のサイトからリンクが張られたことを自動的に通知するためのシステムです。リンクを張る本人は何も意識する必要がありません。リンクを自動的に検知するための手順にしたがって操作すればよく、特別な作業は不要です。pinback を伴う blog の書き込みは、たとえば次のようになります。

1. アリスさんが自分のブログに書き込みをします。その内容にはボブさんの blog へのリンクが含まれています。
2. アリスさんのブログシステムはボブさんのブログシステムへ接続し、「アリスさんがあなたの記事へリンクした記事をかきますた。」と通知します。
3. その結果、ボブさんのブログシステムは該当記事にアリスさんの記事への逆リンクを追加します。
4. ボブさんの記事の読者はそのリンクを辿って、アリスさんがボブさんの記事に対して書いた感想を読むことが可能になります。

このようにしてリンクのチェーンを逆に辿ることが可能になります。

1.1. 技術的な詳細

pingback の仕組みは自動検知に HTTP ヘッダと、HTML または XHTML の <link> 要素を利用しており、リンク元サイトからリンク先サイトへの通知は1回の XML-RPC コールでおこないます。

仕様に準拠した pingback クライアントと pingback サーバは、標準的な CGI 環境で使えるライブラリを用いて、最低限の労力で実装できるよう配慮しています。このため、HTML ヘッダと HTML ドキュメントのパース処理に関する要求仕様も最低限にとどめています。

1.2. 用語の定義

ソース URI

リンクを含むサイトのエントリのアドレスです。

pingback クライアント

サーバへの接続を確立し、ソースからターゲットへのリンクを通知するソフトウェア。通常はソースはクライアントのことを指す。

pingback 有効なリソース

pingback HTTP ヘッダ または pingback link 要素 を使った pingback サーバがあることを知らせている文書、イメージ、その他のリソース。

pingback サーバ

XML-RPC による接続を受け付けるソフトウェア。通常、ターゲット URI のホスト名はそのサーバ自身となる(つまり、同じホスト)。

pingback ユーザエージェント

単独で pingback クライアントと pingback サーバ、両方の機能をこなすシステム。

ターゲット URI

ソースサイトにおけるリンク先。ターゲットはpingback 有効なページでなくてはなりません(SHOULD)。

この文書で用いているキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" および "OPTIONAL" は [RFC 2119] に記述されている内容にしたがって解釈してください。

2. サーバの自動検知

pingback サーバの自動検知にはHTML(または XHTML)の<link> 要素を使う方法と、HTTP　ヘッダを使う方法の2通りがあります。pingback 有効なリソース は X-Pingback HTTP ヘッダ または <link> 要素のどちらか一方、または両方を提供しなければなりません(MUST)。Pingback 有効な HTML、XHTML ページは Valid なものでなければなりません(MUST)。クライアントは Valid でないページの pingback 情報検索を拒否してもかまいません(MAY)。

クライアントがどのようにして、ソースとターゲットの URI を得るかは、この仕様書の範囲外であることに注意してください。通常のやり方としては、ブログに書き込んだ内容を展開し、外部へのリンクからターゲット URI を抽出するようにします。

2.1. HTTP ヘッダ

Pingback 有効なリソースは HTTP ヘッダで X-Pingback を返すことができます(MAY)。たとえば pinback 有効な PNG イメージは次のようなヘッダとともに提供されます。

HTTP/1.1 200 OK
Date: Sun, 08 Sep 2002 15:05:37 GMT
Server: Apache/1.3.26 (Unix)
Last-Modified: Thu, 28 Dec 2000 03:18:26 GMT
ETag: "65044-15b9c-3a4ab102"
Accept-Ranges: bytes
Content-Length: 88988
Connection: close
Content-Type: image/png
X-Pingback: http://charlie.example.com/pingback/xmlrpc

.PNG...
  

TX-Pingback ヘッダの値は XML-RPC サーバの絶対 URI でなければなりません(MUST)。

ページは1個の X-Pingback ヘッダしか出力してはなりません(MUST NOT)。HTML および XHTML ドキュメントは HTTP ヘッダのほかに <link> 要素を含んでもかまいません(MAY)が、これは推奨されません。含める場合は、ヘッダと <link> の値が完全に同じものでなければなりません(SHOULD)。両者がもし一致しない場合は、ヘッダの値で <link> 要素の値を上書きしてもかまいません(SHALL)が、クライアントの環境によっては、HTTP ヘッダを処理できない場合があるので、コンテンツを書く側で注意する必要があります。

Pingback 有効なリソースで pingback サーバを通知するために HTTP Link ヘッダを使ってはいけません(MUST NOT)。 HTTP Link ヘッダは厳密なパースが必須となるため、pingback サーバの自動検知という目的にはオーバースペックだからです。

2.2. Link 要素

pingback 有効な HTML、XHTML ページは次のどちらか一方の形式の <link> 要素を含むことができます(MAY)。

HTML

<link rel="pingback" href="pingback server">

XHTML

<link rel="pingback" href="pingback server" />

link 要素を用いる場合は正しい形式で記述されていなければなりません(MUST)(たとえばスラッシュの前にはスペースを入れる等)。

ページは1個の link 要素しか含んではなりません(MUST NOT)。また、要素の値には後述するパターンの文字は使用できません(MUST NOT)。これは link 以外の要素にも同じことがいえます。

pingback サーバのプレースホルダは、必ず XML-RPC サーバの絶対 URI に置換されていなければなりません(MUST)。URI には &、<、>、" 以外のエンティティは使用できません(MUST NOT)。これ以外に HTML で許されない文字やドキュメントのエンコーディングでは表記できない文字を使う場合は、[RFC2396] に述べられている %xx の表記法を使ってエスケープしなくてはなりません(MUST)。

ここでの要求仕様が厳格なのは、クライアントにサーバ自動検知機能を実装するにあたり、必要となる要件を大幅に軽減するためです。クライアントに XML パーサのほか、HTML パーサを要求するのは負担が重すぎ、ページを書く側に上記のような制限を与える方がむしろ容易だと考えました。

2.3. 自動検知アルゴリズム

ソース URI と ターゲット URI を与えられた Pingback クライアントは、次の手順に従ってターゲット URI から pingback サーバの URI を見つけなければななりません(SHOULD)。

1. レスポンスの HTTP ヘッダの内容を調べます。X-Pingback ヘッダが見つかったら、その値を pingback サーバの URI として使用します。クライアントは HTTP ヘッダを認識可能かを調べなくてはなりません(MUST)。もしなんらかの理由で HTTP ヘッダが認識できなければ、このステップはスキップしてもかまいません(MAY)。しかし、そのような実装をおこなった場合、link 要素が HTML や　XHTML で他の目的に使えなくなってしまい、アプリケーションの使い勝手が損なわれてしまうことに注意してください。HTTP ヘッダと link 要素の値が異なる場合、HTTP ヘッダの値で上書きされてしまうことにも注意が必要です。
2. 見つからなければ、body の実体を調べ、次の正規表現に最初にマッチするものを探します。

   <link rel="pingback" href="([^"]+)" ?/?>

3. 正規表現にマッチするものが見つかったら、クライアントは4つの許可されているエンティティを展開しなければなりません(MUST)(& の &、< の <、> の >、" の ")。

展開された pingback サーバの URI は後述の XML-RPC リクエストの送信に使用します。

X-Pingback ヘッダがなく、正規表現にもマッチしない場合、ターゲットはこの仕様に準拠していないと考えられ、クライアントはどのように処理してもかまいません(MAY)。ただしクライアントにこれ以上寛大な処理(たとえば完全な HTML のパースをおこない、HTML のレベルで pingback の link と思われる <link> を探し出すことなど)は実行させないことを推奨します(RECOMMENDED)。そのようなことをすると、あるシステムでは link を認識できて、別のシステムでは認識できないという状況を発生させてしまうからです。

クライアントは次のような検索処理の最適化も可能です(MAY)。

• クライアントにまず HTTP HEAD リクエストだけを送信させ、ヘッダが見つかったら、コンテンツ本体の検索を省略させてもかまいません(MAY)。
• <link> 要素は head 要素の中にだけ現れるので、(クライアントが行単位で読み込み処理をおこなっている場合) </head> や <body> が現れた時点で、検索を終了させてもかまいません(MAY)。
• pingback の links は通常ドキュメントの冒頭に現れるので、クライアントが一定量のデータを検索した時点で、処理を終了させてもかまいません(MAY)。同様に Content-Range ヘッダを使い、ターゲット URI の最初の数キロバイトだけを検索させてもかまいません(MAY)。

ただし、これらの最適化をおこなうと正当なドキュメントを見逃してしまう可能性もあります。たとえば、コメントや大量のインラインスタイルシートが pingback link の前に書かれている場合などです。ページを記述する側は、これらの最適化が可能なように pingback link を配置することを努めてください。

3. XML-RPC インターフェース

pingback サーバを見つけた Pingback クライアントは、サーバに XML-RPC リクエストを送信しなければなりません(SHOULD)。 リクエストはメソッド名 pingback.ping にソース URI とターゲットURI の2つのパラメータを指定します。 [XML-RPC]

pingback.ping

サーバに sourceURI から targetURI へのリンクが追加されたことを通知します。

パラメータ

sourceURI (型は string)

ターゲットサイトへのリンクを含むソースページの絶対 URI。

targetURI (型は string)

ソースページに記述されているリンクターゲットの絶対 URI。

戻り値

型は string で、以下に述べる内容です。

Faults

エラーが発生した場合は、以下のリストにある適切な fault コードを使用します。クライアントは fault コードを5から8ビット読めば、エラーの内容を判別できます。0x001x fault コードはソース URI のエラーを意味します。0x002x はターゲット URI のエラーです。0x003x は URI は正しいものの、何らかの理由で pingback が受け付けられなかったことを意味します。

0

汎用の fault コード。エラー原因が特定できないなど、他のエラーコードにあてはまらないエラーのとき、サーバはこのエラーコードを使用できます(MAY)。

0x0010 (16)

ソース URI が存在しない。

0x0011 (17)

ソース URI のデータにターゲット URI へのリンクが存在しないため、ソースとして使用できない。

0x0020 (32)

指定されたターゲット URI が存在しない。これはターゲットがまったく存在しないときにだけ使用しなければなりません(MUST)。ターゲット自体は存在するが、利用できない場合については、次のエラーを参照してください。

0x0021 (33)

指定された URI はターゲットとして使用できない。ターゲットが存在しないか、あるいは pingback 有効なリソースではない場合です。通常ブログでは permalink ページだけが pinback 有効になっています。ホームページや投稿の一覧に対して pingback しようとしたときにこのエラーを返します。

0x0030 (48)

既に pingback 登録済み。

0x0031 (49)

アクセス拒否。

0x0032 (50)

アップストリームサーバとの交信に失敗、あるいはアップストリームサーバからエラーが返されたため、リクエストされた内容が完了しなかった。これは HTTP の 402 Bad Gateway エラーに似ています。 このエラーは pingback プロクシにおいて、転送エラーが発生したときに使用します(SHOULD)。

さらにサーバの上位アプリケーションレベルのエラーを通知するために、[FaultCodes] を定義できます(MAY)。

サーバはこのメソッド呼び出しに対して、1個の文字列または fault コードで応答しなくてはなりません(MUST)。

pinback リクエストが成功のとき、サーバは有用と考えられる何らかの情報を1個の文字列を戻り値として返さなくてはなくてはなりません(MUST)。この文字列はデバッグ目的にのみ使われます。

リクエストが失敗したとき、サーバは RPC fault コードで応答しなくてはなりません(MUST)。fault コードは上記一覧の中のどれかひとつ、もしくは fault コードを特定できないときに使う汎用 falut コードの0になります。

クライアントはリクエストが成功したかどうかの戻り値を無視してもかまいません(MAY)が、成功した場合、ユーザには何も知らせないことを推奨します(RECOMMENDED)

リクエストの受信にあたってサーバはどのような処理をしてもかまいません(MAY)が、次の手順でおこなうことを推奨します(RECOMMENDED)。

1. サーバはソース URI が本当にターゲットにリンクしているかどうか調べてもかまいません(MAY)。
2. サーバはターゲットの存在と有効なエントリであることを確認するために、そのデータをチェックしてもかまいません(MAY)。
3. サーバは既に pingback 登録がされていないかどうかを確認してもかまいません(MAY)。
4. サーバは pingback の記録を残してもかまいません(MAY)。
5. (サイトのページがスタティックなものなら)サーバはページを再生成してもかまいません(MAY)。

4. 仕様への準拠

pingback クライアントをこの仕様に準拠させるには、この仕様書に書かれているサーバ自動検知をサポートし(MUST)、pingback XML-RPC コールを正しく送信できなければなりません(MUST)。

pingback サーバをこの仕様に準拠させるには、pingback XML-RPC コールを受信可能で(MUST)、常に仕様で許可された戻り値を返せなくてはなりません(MUST)。非ゼロ fault コードの詳細情報を返すかどうかはオプションです(OPTIONAL)。

pingback サーバによっては、ページと無関係な場合があることに注意してください。たとえば、スタンドアローンの pingback ゲートウェイを使った場合、link 要素のリンク先は、コンテンツのあるサーバではなく、ゲートウェイになります。pingback 有効なリソースをこの仕様に準拠させるには、サーバ自動検知に必要な HTTP X-Pingback ヘッダ か link 要素 のいずれかを提供しなければなりません(MUST)。

pingback ユーザエージェントをこの仕様に準拠させるには、この仕様書に書かれているサーバ自動検知をサポートしていること(MUST)、pingback XML-RPC コールを正しく送信できること(MUST)、pingback XML-RPC コールの受信が可能なこと(MUST)、常に仕様で許可された戻り値を返せること(MUST) - (非ゼロの fault コードの詳細を返すかどうかはオプション(OPTIONAL)、サーバ自動検知に必要な HTTP X-Pingback ヘッダ か link 要素 のいずれかを、潜在的にターゲットとなり得るすべてのページで提供できること(MUST)が必要です。

5. 例

はじめにのところで述べた、アリスさんとボブさんの間で起きたことを、もう少し詳しく見てみましょう。

1. アリスさんは自分のブログに記事の投稿をします。投稿内容には、ボブさんのブログへのリンクが含まれています。アリスさんの記事の permalink は http://alice.example.org/#p123 です。ボブさんのブログへのリンクは http://bob.example.net/#foo です。
2. アリスさんのブログシステムは、投稿された記事の中にある外部リンクをチェックし、http://bob.example.net/#foo のリンクを見つけます。
3. ブログシステムは、リンク先に冒頭の5キロバイトを送るようリクエストします。
4. ブログシステムは、X-Pingback ヘッダを探しましたが、見つかりませんでした。
5. ブログシステムはページの残り部分に pingback link タグがないかどうかを調べ、 次の内容を見つけました。

   <link rel="pingback" href="http://bob.example.net/xmlrpcserver">

   もしこのタグが見つからなかったときは、ボブさんのブログが pingback をサポートしていないことになり、アリスさんのブログシステムはここであきらめます(別のリンクがある場合はステップ2に戻ります)。
6. link 要素が見つかった場合、ブログシステムは次の XML-RPC コールを実行します。 http://bob.example.net/xmlrpcserver:

   pingback.ping('http://alice.example.org/#p123', 'http://bob.example.net/#foo')

7. アリスさんのブログシステムは記事の中にある外部リンクの数だけ、3から6のステップをくり返します。

アリスさん側のシステムの仕事はこれで終わりです。残りの仕事はボブさんのブログでおこなわれます。

1. ボブさんのブログシステムは、アリスさんのブログから(上記ステップ6で送られた) ping を受信します。アリスさんのサイト http://alice.example.org/#p123 から ボブさんのサイト http://bob.example.net/#foo リンクしているという内容です。
2. ボブさんのブログシステムは、このブログに http://bob.example.net/#foo で示される記事があることを確認します。
3. 次に、http://alice.example.org/#p123 をリクエストして Content-Type をチェック、それが何らかのテキストであることを確認します。
4. それから、コンテンツの中にリンクhttp://bob.example.net/#foo があることを確かめます(pingback スパム行為の予防です)。
5. ボブさんのブログシステムはさらに、アリスさんの記事からページタイトルや、ボブさんへのリンク周辺にあるコンテンツを受信します。使用言語に関する属性があれば、それも一緒に受信します。
6. これでボブさんの記事に対する pingback がデータベースに入り、参照されているページは再生成されます。その結果、ボブさんの記事に pingback が表示されるようになります。

A. 参考文献

[RFC 2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. RFC 2119 is available at http://www.normos.org/ietf/rfc/rfc2119.txt.

[RFC 2396]

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. IETF, August 1998. RFC 2396 is available at http://www.normos.org/ietf/rfc/rfc2396.txt

[XML-RPC]

XML-RPC Specification, D. Winer. UserLand Software, Inc, June 1999. XML-RPC is available at http://www.xmlrpc.com/spec

[FaultCodes]

Specification for Fault Code Interoperability, D. Libby, et al. May 2001. The Specification for Fault Code Interoperability is available at http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

最終更新 2003-08-14 23:02:40

Pingback 1.0 の日本語訳。