Kurzfassung

Pingback ist eine Methode für Webautoren, Nachricht zu erhalten, wenn jemand auf eines ihrer Dokumente verlinkt. Üblicherweise kann anstelle des Benutzers entsprechende Webveröffentlichungssoftware die betroffenen Parteien informieren, was es ermöglicht, automatisch Links zu den verweisenden Seiten zu erstellen.

Beispiel: Bob schreibt einen interessanten Artikel in seinem Weblog. Alice liest diesen Artikel und kommentiert ihn, wobei sie zurück auf Bobs ursprünglichen Eintrag verlinkt. Über Pingback kann Alice’ Software Bob automatisch benachrichtigen, dass auf seinen Beitrag verlinkt wurde, und Bobs Software kann diese Information daraufhin auch auf seiner Website verwenden.

Status dieses Dokuments

Dies ist eine stabile Spezifikation. Kommentare werden auf der Blogite-Mailingliste (Archiv) entgegengenommen.

Es gibt derzeit sechs bekannte und separate Implementierungen dieser Spezifikation, obwohl keine formalen Tests durchgeführt wurden, um zu prüfen, wie konform diese sind:

• Simon Willisons Weblog (Ankündigung)
• Stuart Langridges Weblog (Ankündigung)
• Nicholas Avenells Epistula (Ankündigung, Quellcode)
• Michel Valdrighis b2 (Ankündigung)
• Ian Hicksons Weblog (Quellcode)
• Ian Hicksons Pingback-Proxies (Quellcode)

Autoren werden angeregt, http://www.hixie.ch/specs/pingback/pingback zu »pingbacken«, um ihre Implementierungen anzumelden.

Verfügbare Sprachen

Die englische Version dieser Spezifikation ist die einzig normative Version. Beachten Sie jedoch http://www.hixie.ch/specs/pingback/translations/ für Übersetzungen dieses Dokuments. Derzeit verfügbar ist:

• Japanisch, übersetzt von Yasushi Iwata
• Spanisch, übersetzt von Ignacio Javier

Inhaltsverzeichnis

• 1. Einleitung
  • 1.1. Technische Details
  • 1.2. Definitionen
• 2. Server-Autodiscovery
  • 2.1. HTTP-Header
  • 2.2. link-Element
  • 2.3. Autodiscovery-Algorithmus
• 3. XML-RPC-Schnittstelle
• 4. Erfüllungsanforderungen
• 5. Beispiel
• A. Referenzen

1. Einleitung

Das Pingback-System bietet für ein Blog eine Möglichkeit, automatisch benachrichtigt zu werden, wenn andere Websites darauf verlinken. Es ist dabei vollständig transparent für den verlinkenden Autor, erfordert kein Eingreifen des Benutzers und arbeitet auf dem Grundsatz der automatischen Erkennung von allem, was es wissen muss. Ein Beispiel-Szenario, das Pingback einbezieht, kann wie folgt aussehen:

1. Alice schreibt etwas in ihrem Blog. Der Beitrag, den sie verfasst, beinhaltet einen Link zu einem Beitrag in Bobs Blog.
2. Alice’ Blogsystem kontaktiert das von Bob und sagt: »Schau, Alice hat etwas geschrieben, das auf einen von deinen Beiträgen verlinkt.«
3. Bobs Blogsystem erstellt im Originalbeitrag daraufhin einen Link zu Alice’ Beitrag.
4. Leser von Bobs Artikel können diesem Link folgen, um Alice’ Meinung zu lesen.

Pingback ermöglicht somit »umgekehrte Verlinkung«.

1.1. Technische Details

Der Pingback-Mechanismus verwendet einen HTTP-Header und ein HTML- bzw. XHTML-link-Element zur Autodiscovery sowie einen einzelnen XML-RPC-Call, um die Zielseite über den Link auf der Quellseite zu benachrichtigen.

Es ist beabsichtigt, dass konforme Pingback-Clients und -Server unter minimalen Anstrengungen implementiert werden können, indem Bibliotheken verwendet werden, die üblicherweise in CGI-Umgebungen verfügbar sind. Aus diesem Grund sind die Anforderungen an das Parsen von HTTP-Headern und HTML-Dokumenten auf ein absolutes Minimum beschränkt worden.

1.2. Definitionen

Quell-URI

Adresse der Seite mit dem Eintrag, der den Link beinhaltet.

Pingback-Client

Software, die eine Verbindung herstellt, um den Server über den Link von der Quelle zum Ziel zu informieren. Üblicherweise wird die Quelle selbst dieser Client sein.

Pingbackfähige Ressource

Ein Dokument, Bild oder eine andere Ressource, die auf einen Pingback-Server über einen Pingback-HTTP-Header oder ein Pingback-link-Element verweist.

Pingback-Server

Software, die XML-RPC-Verbindungen akzeptiert. Üblicherweise wird der Ziel-URI mit diesem Server assoziiert.

Pingback-User-Agent

Ein einzelnes System, das sowohl einen Pingback-Client als auch einen Pingback-Server darstellt.

Ziel-URI

Das Ziel des Links auf der Quellseite. Dies SOLLTE eine pingbackfähige Seite sein.

In dieser Spezifikation sind die Schlüsselwörter »MUSS«, »DARF NICHT«, »NOTWENDIG«, »SOLL«, »SOLL NICHT«, »SOLLTE«, »SOLLTE NICHT«, »EMPFOHLEN«, »DARF« und »OPTIONAL« zu verstehen wie in [RFC 2119] beschrieben.

2. Server-Autodiscovery

Es gibt zwei Mechanismen für die automatische Ermittlung (Autodiscovery) von Pingback-Servern: HTML- bzw. XHTML-link-Elemente und HTTP-Header. Eine pingbackfähige Ressource MUSS entweder mit einem X-Pingback-HTTP-Header ausgeliefert werden oder ein link-Element beinhalten (oder beides). Pingbackfähige HTML- und XHTML-Seiten MÜSSEN valid sein – Clients DÜRFEN es ablehnen, invalide Seiten nach Pingback-Daten zu durchsuchen.

Beachten Sie, dass es außerhalb dieser Spezifikation liegt, zu definieren, wie der Client von Quell- und Ziel-URIs erfährt. Üblicherweise werden Blogs die externen Adressen ihrer veröffentlichten Beiträge ermitteln, um deren Ziel-URIs zu bestimmen.

2.1. HTTP-Header

Pingbackfähige Ressourcen DÜRFEN mit einem X-Pingback-HTTP-Header zurückgegeben werden. So zum Beispiel wäre ein PNG-Bild mit den folgenden Headern pingbackfähig:

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 …

Der Wert des X-Pingback-Headers MUSS dem absoluten URI des Pingback-XML-RPC-Servers entsprechen.

Ressourcen DÜRFEN NICHT mehr als einen Header beinhalten. HTML- und XHTML-Dokumente DÜRFEN neben einem HTTP-Header auch ein link-Element umfassen, obwohl hiervon abgeraten wird; der Header SOLLTE in diesem Fall jedoch denselben Wert wie das link-Element haben. Sollte eine Diskrepanz vorliegen, SOLL der HTTP-Header Vorrang vor dem link-Element haben, aber Autoren sollte bewusst sein, dass manche Clients HTTP-Header aufgrund von Einschränkungen ihrer Umgebung nicht verarbeiten können.

Pingbackfähige Ressourcen DÜRFEN NICHT die HTTP-Link-Header verwenden, um auf Pingback-Server zu verweisen. HTTP-Link-Header erfordern kein triviales Parsen, und sie werden aus diesem Grund als zu leistungsfähig für die Zwecke der Pingback-Server-Autodiscovery angesehen.

2.2. link-Element

Eine pingbackfähige HTML- oder XHTML-Seite DARF ein link-Element in einer der folgenden zwei Formen beinhalten:

HTML

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

XHTML

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

Das link-Element MUSS exakt dieser Form entsprechen, wenn es verwendet wird (also einschließlich des Leerraums vor dem Slash).

Seiten DÜRFEN NICHT mehr als ein solches Element und auch keine Zeichenkette nach dem unten beschriebenen Muster beinhalten, solange es nicht dem link-Element selbst entsprechen soll.

Der pingback server-Platzhalter MUSS durch den absoluten URI des Pingback-XML-RPC-Servers ersetzt werden. Dieser URI DARF KEINE Entitätsreferenzen außer &, <, > und " umfassen. Andere Zeichen, die im HTML-Dokument nicht valid wären oder die nicht über die Zeichenkodierung des Dokuments dargestellt werden können, MÜSSEN über den %xx-Mechanismus maskiert werden, der in [RFC 2396] beschrieben wird.

Diese strikten Maßgaben dienen dazu, die Anforderungen an Clients, die Server-Autodiscovery implementieren, drastisch zu reduzieren. Es wurde als zu hohe Belastung angesehen, von Clients neben dem XML- auch die Implementierung eines zusätzlichen HTML-Parsers zu verlangen, wenn man bedenkt, wie einfach es für Seitenautoren ist, den oben beschriebenen Restriktionen zu folgen.

2.3. Autodiscovery-Algorithmus

Pingback-Clients SOLLTEN, wenn Ihnen Quell- und Ziel-URI übergeben werden, den Ziel-URI abrufen und die folgenden Schritte befolgen, um den URI des Pingback-Servers zu ermitteln.

1. Kontrolliere die HTTP-Header der Antwort. Wenn es irgendwelche X-Pingback-Header gibt, sollte der Wert des ersten solchen Headers als Pingback-Server-URI verwendet werden. Clients MÜSSEN die HTTP-Header überprüfen, wenn sie dazu in der Lage sind. Falls aus irgendeinem Grund der Implementierung keine HTTP-Header zur Verfügung stehen, DARF dieser Schritt übersprungen werden – Implementierern sollte jedoch bewusst sein, dass dies die Nützlichkeit ihrer Anwendung reduziert, da link-Elemente nicht für Ressourcen verwendet werden können, die weder HTML noch XHTML sind, und dass HTTP-Header so definiert wurden, dass sie link-Elemente nichtig machen, wenn beide unterschiedlich sind.
2. Durchsuche andernfalls den Entitätenkörper nach der ersten Übereinstimmung mit dem folgenden regulären Ausdruck:

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

3. Wenn der reguläre Ausdruck zutrifft, MÜSSEN Clients die vier erlaubten Entitätsreferenzen erweitern (& für &, < für <, > für > und " für ").

Wenn der Pingback-Server-URI ermittelt wurde, SOLLTE dieser verwendet werden, um wie unten beschrieben einen XML-RPC-Request zu senden.

Wenn es keinen X-Pingback-Header gibt und der reguläre Ausdruck auf nichts zutrifft, unterstützt das betroffene Ziel kein Pingback, wie es in dieser Spezifikation definiert wird, und der Client DARF tun, was er möchte. Es ist jedoch EMPFOHLEN, dass Clients nicht versuchen, noch nachsichtiger zu sein (zum Beispiel, indem das HTML geparst und nach link-Elementen gesucht wird, die aus HTML-Gesichtspunkten nach Pingback-Links aussehen), da dies zu Systemen führen wird, die einen solchen Link erkennen, und anderen, die ihn ignorieren.

Clients DÜRFEN die Suche optimieren. Beispiele:

• Der Client DARF initial einen HTTP-HEAD-Request senden, in der Hoffnung, dass der X-Pingback-Header gefunden wird und der Inhalt gar nicht erst abgeholt werden muss.
• Da link-Elemente nur im Dokumentenkopf verwendet werden dürfen, DÜRFEN Clients abbrechen, wenn auf die Zeichenketten </head> oder <body> gestoßen wird (falls Clients den Inhalt zum Beispiel Zeile pro Zeile lesen).
• Da Pingback-Link höchstwahrscheinlich am Anfang eines Dokuments auftauchen, DÜRFEN Clients die Suche abbrechen, wenn ein bestimmter Größen-Grenzwert überschritten wurde. Clients DÜRFEN analog dazu den HTTP-Content-Range-Header verwenden, um nur die ersten Kilobytes des Ziel-URI anzufordern.

Beachten Sie jedoch, dass diese Verbesserungen dazu neigen, von legitimen Dokumenten überholt zu werden, wenn in diesen zum Beispiel die obigen Zeichenketten auskommentiert wurden oder große interne Stylesheets vor den Pingback-Links erscheinen. Autoren sollten diese möglichen Optimierungen berücksichtigen, wenn es darum geht, wo sie ihre Pingback-Links platzieren sollen.

3. XML-RPC-Schnittstelle

Pingback-Clients, die einen Pingback-Server ermittelt haben, SOLLTEN diesem einen XML-RPC-Request mit dem Methodennamen pingback.ping sowie zwei Argumenten senden, nämlich dem Quell- bzw. dem Ziel-URI. [XML-RPC]

pingback.ping

Benachrichtigt den Server darüber, dass ein Link auf sourceURI hinzugefügt wurde, der auf targetURI verweist.

Parameter

sourceURI, Typ string

Der absolute URI des Beitrags auf der Quellseite, der den Link auf die Zielseite beinhaltet.

targetURI, Typ string

Der absolute URI des Linkziels, wie er auf der Quellseite angegeben wird.

Rückgabewert

Ein string, wie unten beschrieben.

Fehler

Wenn ein Fehler auftritt, sollte der entsprechende Fehlercode aus der nun folgenden Liste verwendet werden. Clients können aus den Bits 5–8 schnell die Art des Fehlers ermitteln. Die Fehler-Codes 0x001x werden für Probleme mit dem Quell-URI, die Codes 0x002x für Probleme mit dem Ziel-URI und die Codes 0x003x dann gebraucht, wenn die URIs in Ordnung sind, aber der Pingback aus anderen Gründen nicht bestätigt werden kann.

0

Ein generischer Fehlercode. Server DÜRFEN diesen Fehlercode anstelle eines anderen verwenden, wenn sie keinen passenden Fehlercode ermitteln können.

0x0010 (16)

Der Quell-URI existiert nicht.

0x0011 (17)

Der Quell-URI beinhaltet keinen Link zum Ziel-URI und kann damit nicht als Quelle verwendet werden.

0x0020 (32)

Der spezifizierte Ziel-URI existiert nicht. Dies DARF NUR verwendet werden, wenn das Ziel definitiv nicht existiert, nicht, wenn das Ziel existieren könnte, aber nicht erkannt wird. Siehe auch den nächsten Fehlercode.

0x0021 (33)

Der spezifizierte Ziel-URI kann nicht als Ziel verwendet werden. Entweder er existiert nicht oder er ist keine pingbackfähige Ressource. In einem Blog sind zum Beispiel nur Permalinks (permanente Links) pingbackfähig, und der Versuch, die Homepage oder einen Satz von Beiträgen zu »pingbacken«, wird diesen Fehler ergeben.

0x0030 (48)

Der Pingback wurde bereits erfasst.

0x0031 (49)

Zugriff verweigert.

0x0032 (50)

Der Server kann nicht mit einem Upstream-Server kommunizieren oder er empfing einen Fehler von einem Upstream-Server und kann den Request aus diesem Grund nicht vollständig bearbeiten. Dies ist dem HTTP-Fehler 402 Bad Gateway ähnlich. Diese Meldung SOLLTE von Pingback-Proxies verwendet werden, wenn sie Fehler propagieren.

Zusätzlich definiert [FaultCodes] einige Standardfehlermeldungen, die Server verwenden DÜRFEN, um spezifischere Fehler zu melden.

Server MÜSSEN auf diesen Funktionsaufruf antworten, entweder mit einer einzelnen Zeichenkette oder mit einem Fehlercode.

Wenn der Pingback-Request erfolgreich ist, MUSS der Rückgabewert eine einzelne Zeichenkette sein, die so viele Informationen beinhaltet, wie es der Server für nützlich erachtet. Von dieser Kette wird erwartet, dass sie ausschließlich für Debug-Zwecke verwendet wird.

Wenn das Ergebnis nicht erfolgreich ist, MUSS der Server mit einem RPC-Fehlercode antworten. Der Fehlercode sollte entweder einem der oben aufgezählten Codes oder dem generischen Code »Null« entsprechen, wenn der Server keinen angemessen Fehlercode ermitteln kann.

Clients DÜRFEN den Rückgabewert ignorieren, egal ob der Request erfolgreich war oder nicht. Es wird EMPFOHLEN, dass Clients dem Benutzer nicht die Ergebnisse erfolgreicher Requests zeigen.

Nach Empfang eines Request DÜRFEN Server tun, was sie wollen. Es werden jedoch die folgenden Schritte EMPFOHLEN:

1. Der Server DARF versuchen, den Quell-URI anzufordern, um zu verifizieren, dass die Quelle tatsächlich auf das Ziel verlinkt.
2. Der Server DARF die eigenen Daten prüfen, um sicherzustellen, dass das Ziel existiert und einen validen Eintrag darstellt.
3. Der Server DARF prüfen, ob der Pingback bereits erfasst wurde.
4. Der Server DARF den Pingback aufzeichnen.
5. Der Server DARF die Seiten der Website neu generieren (falls diese statisch sind).

4. Erfüllungsanforderungen

Um Konformität zu dieser Spezifikation geltend machen zu können, MUSS ein Pingback-Client Server-Autodiscovery unterstützen, wie es in dieser Spezifikation beschrieben wird, und er MUSS Pingback-XML-RPC-Calls korrekt senden können.

Um Konformität zu dieser Spezifikation geltend machen zu können, MUSS ein Pingback-Server Pingback-XML-RPC-Calls empfangen sowie stets Ergebnisse zurückgeben, die den erlaubten Rückgabewerten entsprechen. Die Rückgabe detaillierterer Fehler-Codes (die nicht Null sind), ist OPTIONAL.

Beachten Sie, dass manche Pingback-Server über keine assoziierten Seiten verfügen. Beispielsweise könnte ein Pingback-Gateway-Server für sich allein (»standalone«) stehen, und andere Seiten würden dann das link-Element gebrauchen, um zu diesem Gateway-Server zu verlinken, anstatt selbst einen Server anzubieten. Um Konformität zu dieser Spezifikation geltend machen zu können, MUSS eine pingbackfähige Ressource entweder über einen HTTP-X-Pingback-Header oder ein link-Element verfügen, um Server-Autodiscovery zu ermöglichen.

Um Konformität zu dieser Spezifikation geltend machen zu können, MUSS ein Pingback-User-Agent Server-Autodiscovery unterstützen, wie es in dieser Spezifikation beschrieben wird, Pingback-XML-RPC-Calls korrekt senden und empfangen können, immer Ergebnisse zurückgeben, die den erlaubten Rückgabewerten entsprechen (wobei die Rückgabe detaillierterer Fehler-Codes, die nicht Null sind, OPTIONAL ist) und entweder über HTTP-X-Pingback-Header oder ein link-Element auf allen potentiellen Zielseiten verfügen, um Server-Autodiscovery zu ermöglichen.

5. Beispiel

Hier folgt ein detaillierterer Blick darauf, was zwischen Alice und Bob während des in der Einleitung beschriebenen Szenarios passieren könnte.

1. Alice schreibt etwas in ihrem Blog. Der Beitrag, den sie verfasst, beinhaltet einen Link zu einem Beitrag in Bobs Blog. Der Permalink zu Alice’ neuem Beitrag lautet http://alice.example.org/#p123, und die URL des Links zu Bobs Blog lautet http://bob.example.net/#foo.
2. Alice’ Blogsystem parst alle externen Links in ihrem Beitrag und findet http://bob.example.net/#foo.
3. Es fordert daraufhin die ersten fünf Kilobytes der Seite an, auf die sich der Link bezieht.
4. Es sucht nach einem X-Pingback-Header, findet jedoch keinen.
5. Es sucht das Seitenfragment nach dem Pingback-link-Element ab, das es schließlich findet:

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

   Wenn die Seite dieses Element nicht beinhaltet hätte, würde Bobs Blog kein Pingback unterstützen, und Alice’ Software hätte an dieser Stelle abgebrochen (woraufhin es beim nächsten in Schritt 2 gefundenen Link weitermachen würde).
6. Da das link-Element tatsächlich aber da ist, sendet es anschließend den folgenden XML-RPC-Call an http://bob.example.net/xmlrpcserver:

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

7. Alice’ Blogsystem wiederholt Schritt 3 bis 6 bei jedem externen Link, der in ihrem Beitrag gefunden wurde.

An dieser Stelle endet die von Alice’ System durchgeführte Arbeit. Der Rest wird von Bobs Blog ausgeführt.

1. Bobs Blogsystem empfängt einen Ping von Alice’ Blog (der Ping, der im obigen Schritt 6 gesendet wurde), der http://alice.example.org/#p123 (die Seite, die zu Bob verlinkt) und http://bob.example.net/#foo nennt (die Seite, auf die Alice verlinkt) nennt.
2. Bobs Blogsystem bestätigt, dass http://bob.example.net/#foo tatsächlich ein Beitrag in diesem Blog ist.
3. Es fordert nun den Inhalt von http://alice.example.org/#p123 an und prüft den Content-Type der Antwort, um sicherzustellen, dass diese in irgendeiner Form Text beinhaltet.
4. Es stellt fest, dass der Inhalt tatsächlich einen Link auf http://bob.example.net/#foo beinhaltet (um das »Zuspammen« mit Pingbacks zu verhindern).
5. Bobs Blog ermittelt außerdem weitere Daten, die aus dem Inhalt von Alice’ neuen Beitrag erforderlich sind, wie zum Beispiel den Fenstertitel, einen Auszug des Bereichs, der den Link zu Bobs Beitrag umgibt, Attribute, die darauf hindeuten, in welcher Sprache die Seite verfasst wurde &c.
6. Schließlich zeichnet Bobs Blogsystem den Pingback in seiner Datenbank auf und generiert alle statischen Seiten neu, die sich auf Bobs Beitrag beziehen, damit diese den Pingback einbeziehen.

A. Referenzen

[RFC 2119]

Key Words for Use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, März 1997. RFC 2119 ist verfügbar unter http://www.ietf.org/rfc/rfc2119.txt.

[RFC 2396]

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. IETF, August 1998. RFC 2396 ist verfügbar unter http://www.ietf.org/rfc/rfc2396.txt.

[XML-RPC]

XML-RPC Specification, D. Winer. UserLand Software, Inc., Juni 1999. XML-RPC ist verfügbar unter http://www.xmlrpc.com/spec.

[FaultCodes]

Specification for Fault Code Interoperability, D. Libby et al. Mai 2001. Die Specification for Fault Code Interoperability ist verfügbar unter http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php.