Diese Version

Neueste Version

Frühere Versionen

Autoren



Exzerpt

Pingback ist eine Methode, wie Web Autoren Jemanden über einen eigenen Artikel benachrichtigen können. Typischerweise wird eine Web Publishing Software die relevanten Server automatisch informieren. Dies ermöglicht die automatische Erstellung von Verlinkungen relevanter (miteinander in Beziehung stehender) Dokumente.

Ein Beispiel. Alice schreibt einen interessanten Artikel in ihrem Weblog (Blog). Bob liest diesen Artikel, schreibt darüber einen eigenen Artikel und verlinkt zurück zu Alices Artikel. Mit Pingback kann nun Bobs Software Alices Server automatisch über Existenz und Ort von Bobs Artikel informaieren. und Alices Software kann automatisch einen Verweis (Link) zu Bobs Artikel in ihren eigenen Artikel einfügen.

Status dieses Dokuments

Dies ist eine stabile Spezifikation. Sie enthält eine kleine Ergänzung zu Ian Hicksons Spezifikation v1.0. Kommentare/Feedback bitte an mich.

Verfügbare Sprachen

Das Dokument ist verfügbar in Englisch und Deutsch (und in den Formaten html 4.01 und xhtml 1.1). Die gelieferte Version hängt von automatic content negotiation und somit von den Browsereinstellungen ab. Die voreingestellte Version ist Deusch. Die normative Version ist Englisch. Ein Link zur jeweils anderen Version befindet sich im Footer.

Errata

Dieser Teil wurde nachträglich hinzugefügt.

(16.1.2007) Im denial of service Angriffe zu vermeiden sollten pingback Server, die die angegebene Quelle laden (wie unter Punkt 3 beschrieben) unbedingt die Größe des zu untersuchenden Dokuments begrenzen sowie die Datentransferrate. Vielen Dank an Blake Matheny, der dies bekannt gemacht hat.

Inhaltsverzeichnis

  1. Einführung
    1. Technische Details
    2. Definitionen
  2. Server Autodiscovery
    1. HTTP Header
    2. Link Element
    3. Autodiscovery Algorithmus
  3. XML-RPC Interface
  4. Conformance Anforderungen
  5. Beispiel
  6. Referenzen

Einführung

Pingback ist eine Möglichkeit für ein Blog, automatisch darüber benachrichtigt zu werden, wenn andere Webseiten darauf verlinken. Es ist komplett transparent für den verlinkenden Author, benötigt keinerlei Interaktion seitens des Users und arbeitet, indem es Alles, was es wissen muss, automatisch findet. Ein einfacher Blogbeitrag könnte ein pingback etwa so nutzen:

  1. Alice schreibt einen Blogbeitrag. Der Beitrag enthält einen Link zu einem Beitrag in Bobs Blog.
  2. Alices Blogsystem kontaktiert Bobs Blogsystem: "Schau, Alice hat einen Beitrag zu Deinem Beitrag geschrieben".
  3. Bobs Blogsystem fügt nun einen Link auf Alices Folgebeitrag zum eigenen Beitrag hinzu.
  4. Leser von Bobs Artikel können nun diesem Link folgen und sehen, was Alice dazu meint.

Dies ermöglicht umgekehrtes Verlinken - Sozusagen von unten nach oben statt wie üblich von oben nach unten.

Technische Details

Der Pingback Mechanismus nutzt einen HTTP header und ein HTML oder XHTML link Element für Autodiscovery, und nutzt einen einzelnen XML-RPC Aufruf, um das Ziel über den Link auf der Quelle zu benachrichtigen.

Es ist Absicht, dass entsprechende pingback Clients und Server mit minimalem Aufwand erstellt werden können und dazu existierende Libraries für CGI Umgebungen nutzen können. Daher wurden die Anforderungen zum Parsen des HTTP headers und des HTML Dokuments auf das absolute Minimum beschränkt.

Definitionen

sourceURI

Dieser Eintrag ist die Adresse des Dokuments, das den Link enthält.

Dies ist die URI des Dokuments B, das einen Artikel enthält, der sich auf einen Artikel in einem Dokument A bezieht. Wenn Sie einen Artikel zu einem anderen Artikel schreiben, dann ist das Ihre URI.

Das Dokument, das durch sourceURI referenziert wird, sollte per default im Format HTML vorliegen. Der Server sollte das Dokument mit einem http Accept header des Typs text/html, application/xml oder application/rss+xml oder anderen anfordern (die letzen Beiden jeweils eine RSS-Datei). Es ist explizit erlaubt, auch andere mime-Typen anzufordern oder zu erlauben. Wenn der pingback Server das Format nicht parsen kann, kann er nach Bedarf den pingback Request ablehnen oder nur die sourceURI zum eigenen Artikel hinzufügen.

pingback client

Die Software die die Verbindung herstellt, um den Server über den Link zu informieren. Typischerweise wäre die Quelle der Client.

pingback server

Die Software, die den XML-RPC Request annimmt. Typischerweise steht die targetURI in Zusammenhang mit dem Server (e.g. ist auf dem selben Host).

pingback user agent

Ein einzelnes System, das sowohl pingback Server als auch Client ist.

targetURI

Das Ziel des Links. Dieses Ziel sollte pingback unterstützen.

Server Autodiscovery

Es gibt zwei Mechanismen, wie ein pingback Service automatisch gefunden werdne kann: link Elemente und der HTTP header. Eine pingback-enabled Resource muss entweder mit einem X-Pingback HTTP header geliefert werden, oder ein link Element enthalten, oder Beides. Pingback-enabled HTML and XHTML Seiten müssen valide sein. Cliens können die Suche nach pingback Informationen abbrechen, wenn die Seite invalide ist.

HTTP Header

Pingback-enabled Resourcen Können mit einem X-Pingback HTTP header geliefert werden. Zum Beispiel wäre ein PNG Bild, das mit folgendem Header geliefert wird, pingback-enabled:

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 header muss die absolute URI des pingback XML-RPC Servers sein.

Seiten (Resourcen) dürfen nicht mehr als einen solchen Header enthalten. HTML und XHTML Dokumente können ein link Element zusätzlich zum HTTP header enthalten. Dies ist allerdings nicht empfohlen. Wenn enthalten, sollte der header und das link Element exakt den gleichen Wert haben. Falls nicht, hat der HTTP header die höhere Priorität. Authoren sollten sich jedoch darüber bewusst sein, dass manche Clients den HTTP header aufgrund von Einschränkungen nicht verarbeiten können.

Pingback-enabled resources dürfen nicht den HTTP Link header nutzen, um den pingback Service anzuzeigen. HTTP Link headers erfordern nicht-triviales Parsen. Dies erfordert zu viel Rechenaufwand zum Zwech des pingback Server Autodiscovery.

Ein HTML oder XHTML pingback-enabled Dokument kann ein link Element enthalten in einer der folgenden Formen:

html

link rel="pingback" href="pingback server"

html 4.x oder xhtml als text/html geliefert

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

Wenn so genutzt, muss diese Form exakt eingehalten werden (einschließlich beispielsweise des Leerzeichens vor dem Schrägstrich).

xhtml geliefert als text/xml, application/xml or application/xhtml+xml

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

Wenn so genutzt, kann das link Element das Leerzeichen vor dem Schrägstrich enthalten. Es muß den Regeln der xml Wohlgeformtheit entsprechen.

Dokumente dürfen nicht mehr als ein solches Element enthalten und keinen String, der dem unten stehenden Muster entspricht, es sei denn, es ist beabsichtigt, dass das das link Element sein soll.

Der Pingback Platzhalter muß durch die absolute URI des pingback XML-RPC servers ersetzt werden. Diese URI darf keine Entities enthalten ausser &, <, >, and ". Andere Zeichen, die im HTML Dokument invalid wären oder innerhalb der Zeichenkodierung des Dokuments nicht dargestellt werden können, müssen Escaped werden durch %xx, wie in [RFC2396] beschrieben.

Diese sehr strengen Regeln sind so Absicht, um die Anforderungen an die Server Autodiscovery drastisch zu reduzieren. Die Notwendigkeit, sowohl einen HTML Parser als auch einen XML Parser zu implementieren wurde als eine zu große Last angesehen, verglichen mit den sehr einfachen Anforderungen an die Regeln wie oben beschrieben.

Autodiscovery Algorithmus

Pingback clients, die je eine sourceURI und eine targetURI erhalten haben, sollten das Dokument von der targetURI Adresse holen und folgende Schritte ausführen, um die URI des pingback Servers zu finden:

  1. Zunächst soltle der HTTP response header nach einem X-Pingback durchsucht werden. Befindet sich solch einer im header, so ist per Definition der erste davon die URI des pingback Servers. Clients müssen diesen header durchsuchen, wenn sie dazu in der Lage sind. Wenn aus irgendeinem Grund der HTTP header nicht verfügbar ist, kann dieser Schritt notfalls übersprungen werden.
  2. Ansonsten wird das Dokument nach folgender RegExp durchsucht: link +rel="?pingback"? +href=[^ ]+"? *[^>]* */?

    Die originale Regexp war link rel="pingback" href="([^"]+)" ?/?. Die Neue erlaubt etwas mehr Flexibilität ohne das Finden der URI wesentlich komplizierter zu machen, es ist immer noch eine einfache RegExp. Die neue RegExp erlaubt beliebige weitere Attribute, so lange rel="pingback" das erste Attribut ist, und href das zweite Attribut. Attribute können in Anführungszeichen stehen, wie in neueren html Versionen geforder, oder ohne, wie in alten html Versionen möglich. Und die Attribute können durch ein oder mehrere Leerzeichen voneinander getrennt sein.

  3. Falls die RegExp passt, müssen Clients folgende Entities erweitern: (&amp; for &, &lt; for <, &gt; for >, and &quot; for ").

Wenn die pingback server URI gefunden wurde, sollte ein XML-RPC wie unten beschrieben abgeschickt werden.

Wenn kein X-Pingback header gefunden wurde und die RegExp nicht passt, dann bietet das Ziel keinen Pingback Service wie in dieser Spezifikation beschrieben und der Client kann tun, was immer ihm beliebt. Es wird allerdings empfohlen, nicht überklug zu sein und zu versuchen, doch noch durch einen html-Parser Irgendwas zu finden, was vielleicht doch nach einem pingback Link aussieht. Dies würde dazu führen, dass manche Systeme den Link finden, andere nicht.

Clients können die Suche optimieren. Zum Beispiel:

Es sei jedoch angemerkt, dass diese Optimierungen zu Fehlverhalten bei ansonsten völlig korrekten Dokumenten führen können. Zum Beispiel könnten Dokumente Kommentare am Anfang enthalten oder lange umfangreiche inline Stylesheets. Authoren sollten dies berücksichtigen, wenn sie ihren pingback Link platzieren..

XML-RPC Interface

Pingback clients, die die URI des pingback Servers gefunden haben, sollten diesem Server einen XML-RPC Request senden mit dem Methodenname pingback.ping und zwei Parametern, der sourceURI (Quell-URI) und der targetURI (Ziel-URI).

pingback.ping
Benachrichtigt den Server, dass einLink hinzugefügt wurde zu sourceURI, verweisend auf targetURI.

Parameter

sourceURI, Typ string
Die absolute URI des Beitrags auf der Quellseite, die den Link zur Zielseite enthält.
targetURI, Typ string
Die absolute URI Zieldokuments, wie in dem Quelldokument vorhanden.

Rückgabewert

Ein String (s.u.).

Fehler

Im Fehlerfall sollte ein Fehlercode aus der folgenden Liste zurückgegeben werden. Clients können anhand der Bits 5-8 schnell entscheiden, was die Fehlerursache war. 0x001x Fehlercodes zeigen Fehler mit der sourceURI an, 0x002x Codes Fehler mit der targetURI, und 0x003x Codes Fehler, bei denen dem Pingback aus sonst einem Grund nicht entsprochen werden kann.

0
Ein generischer Fehlercode. Server können diesen zurückliefern anstelle der anderen, wenn sie aus irgendeinem Grund keine Möglichkeit haben, die Fehlerursache nächer zu bestimmen.
0×0010 (16)
Das Quelldokument existiert nicht.
0×0011 (17)
Das Dokument enthält keinen Link zum Zieldokument und kann daher nicht verwendet werden.

Bitte neuen Fehlercode beachten.

0x0012 (18) (neu)
Das Quelldokument konnte nicht durchsucht werden aufgrund unbekannten Formats.
0×0020 (32)
Das Zieldokument (targetURI) existiert nicht. Dies darf nur genutzt werden, wenn das Zieldokument tatsächlich nicht existiert, nicht, wenn es existiert aber nicht erkannt wird. Siehe nächster Fehler.
0×0021 (33)
Das Zieldokument kann nicht als Ziel genutzt werden. Entweder existiert es nicht, oder es ist nicht pingback enabled. Zum Beispiel sind in Blogs nur die sogenannten Permalinks pingback enabled. Wenn versucht wird, die Homepage oder eine Kollektion von Posts anzupingen, wird dies mit diesem Fehler daneben gehen.
0×0030 (48)
Der Pingback ist bereits registriert.
0×0031 (49)
Zugriff verweigert.
0×0032 (50)
Der Server konnte keine Verbindung zur Gegenstelle aufbauen, oder erhielt von dort einen Fehler. Das entspricht etwa dem HTTP 402 Bad Gateway Fehler. Dieser Fehlercode sollte von Pingback Proxy Servern genutzt werden, wenn sie Fehler weiter reichen.

Zusätzlich definieren einige standard [FaultCodes] Serverfehler auf höheren Ebenen.

Server müssen auf den XML-RPC entweder mit einem einfachen String oder mit einem Fehlercode antworten.

Wenn der Pingback erfolgreich war, muss ein einfacher String zurückgegeben werden. Dieser String sollte so viel Information enthalten, wie es dem Server für richtig erscheint. Der String dient lediglich Debugging-Zwecken.

Im fehlerfall muss der Server mit dem RPC Fehlercode antworten. Der Fehlercode soltle entweder einer der obigen sein, oder der generische Fehlercode 0, wenn der Server die Fehlerursache nicht bestimmen kann.

Clients können den Rückgabewert ignorieren. Empfohlen wird, erfolgreiche Requests dem User nicht anzuzeigen.

Nach Empfang des Requests können Server tun, was immer ihnen beliebt. Folgende Schritte werden jedoch empfohlen:

  1. Der Server kann das Dokument von sourceURI laden und untersuchen, um zu prüfen, ob es tatsächlich einen Link zu dem Zieldokument enthält.

    Wenn der Server dies tut, muß er in der Lage sein, mindestens die Formate text/html und application/xml sowie application/rss+xml (beides jeweils rss-Format) zu parsen. Der Server sollte bei seiner Anfrage einen passenden http Accept header mitschicken, um den Client darüber zu informaieren, welches Format er gerne hätte. Der Server kann jeden beliebigen weiteren mime Typ zu der Liste hinzufügen.

  2. Wenn das Dokument nicht zu parsen ist, kann der Server den Pingback verwerfen, oder er kann schlicht die sourceURI zu dem Zieldokument hinzufügen. sourceURI to the article.
  3. Der Server kann seine eigenen Daten daraufhin überprüfen, ob das Ziel existiert und gültig ist.
  4. Der Server kann prüfen, ob dieser Pingback nicht bereits registriert wurde.
  5. Der Server kann den Pingback aufzeichnen und speichern.
  6. Der Server kann seine Seiten neu erstellen (falls die Seiten beispielsweise statisch sind).

Conformance Anforderungen

Um den ANforderungen dieser Spezifikaton zu genügen, muß ein Pingback Client server autodiscovery unterstützen wie hier beschrieben, und er muß korrekte pingback XML-RPC Requests senden.

Um den Anforderungen dieser Spezifikation zu genügen muß ein pingback Server einen pingback XML-RPC calls empfangen und verarbeiten können und muß ein Ergebnis zurückliefern, das den zulässigen Rückgabewerten entspricht. Eine Rückgabe detaillierter Fehlerwerte (nicht Null) ist optional.

Anmerkung: Es ist möglich, dass pingback Server keine eigenen Seiten haben. Beispielsweise könnte ein pingback gateway Server unabhängig von der Zielseite existieren. In dem Fall wären die targetURI und die pingback Server URI grundverschieden. Der Verfasser der Bloartikel könnte so auf den Betrieb eines eigenen pingback Servers verzichten und einen externen Dienst nutzen.

Um den Anforderungen dieser Spezifikation zu genügen, muß eine pingback-enabled Resource entweder einen X-Pingback http Header liefern oder ein link element aufweisen, um Server Autodiscovery zu ermöglichen.

Um dieser Spezifikation zu genügen muß ein pingback User Agent Server Autodiscovery ermöglichen, wie hier beschrieben, und muss pingback XML-RPC calls korrekt senden, pingback XML-RPC calls korrekt empfangen, immer ein Resultat liefern, das den zulässigen Rückgabewerten genügt (eine Rückgabe eines detaillierten Fehlercodes (nicht Null) ist optional), und muss entweder einen X-Pingback header senden oder link element aufweisen. Dies gilt für alle potentiellen Zieldokumente, um Server Autodiscovery zu ermöglichen.

Beispiel

Hier ein etwas detaillierteres Beispiel, was im Einzelnen zwischen Alice und Bob vor sich gehen kann wärend des Beispiels, wie in der Einführung beschrieben:

  1. Alice schreibt einen Blogartikel. In ihrem Artikel setzt sie einen Link auf einen Artikel in Bobs Blog. Der Permalink von Alices neuem Artikel ist http://alice.example.org/#p123, und die URI von Bobs Artikel ist http://bob.example.net/#foo.
  2. Alices Blogsystem parst alle externen Links und findet http://bob.example.net/#foo.
  3. Ihr Blogsystem lädt dann die ersten 5KB von der gefundenen URI.
  4. Das Blogsystem sucht nun nach dem X-Pingback header, findet aber keinen.
  5. Es durchsucht nun den geladenen Teil des Dokuments und findet: link rel="pingback" href="http://bob.example.net/xmlrpcserver" Wenn dies nicht vorhanden gewesen wäre, wäre Bobs Blog nicht pingback-enabled, und Alices Software würde hier abbrechen und mit dem nächsten Link bei Schritt 2 fortfahren.
  6. Da der Link gefunden wurde, wir nun ein XML-RPC call an http://bob.example.net/xmlrpcserver geschickt: pingback.ping('http://alice.example.org/#p123', 'http://bob.example.net/#foo')
  7. Alices Blogsystem wiederholt die Schritte 3-6 für alle gefundenen externen Links.

Für Alices System war's das. Der Rest wird von Bobs Blog erledigt.

  1. Bobs Blog empfängt einen Ping (der Ping aus Schritt 6 oben). Dieser nennt http://alice.example.org/#p123 als Quelle und http://bob.example.net/#foo als Ziel, zu dem Alices Blog verweist.
  2. Bobs Blog verifiziert, dass http://bob.example.net/#foo in der Tat ein Blogbeitrag ist.
  3. Dann holt sein Blog das Dokument von http://alice.example.org/#p123 und prüft, ob es sich bei dem Dokument um irgendeine Art von verständlichem Text handelt. Es muss sich bei dem Dokument zumindest entweder um eine html Datei oder eine rss Datei handeln. Andere Formate sind möglich aber optional.
  4. Das Blogsystem verifiziert nun, dass sich in dem Dokument tatsächlich ein Link auf den eigenen Blogbeitrag http://bob.example.net/#foo befindet, um Spam zu vermeiden.
  5. Bobs Blog extrahiert ausserdem weitere Daten aus Alices neuem Beitrag, wie z.B. den Titel und einen Excerpt des Textes um den Link herum, die Sprache des Beitrags, u.s.w.
  6. Zum Schluss speichert Bobs Blogsystem die Informationen us dem Pingback in der eigenen Datenbank und generiert eventuelle Statistiken.

Beispiel "zu Fuß"

Nehmen wir mal etwas Anderes als ein Blog an. Nehmen wir einmal an, dass kein Pingback Client existiert. Dann kann Alice trotzdem einen Pingback an Bobs Blog senden (ein Pingback Server ist trotzdem erforderlich):

  1. Alice veröffentliche Irgendwas im Web. Vorzugsweise sollte dies irgendein html Dokument sein, aber es könnte in der Tat irgendein Dokument sein, das veröffentlicht werden kann. Dieses Dokument steht in einem Zusammenhang mit einem Artikel in Bobs Blog. Alice kennt die URI von Bobs Blogbeitrag: http://bob.example.net/#foo.
  2. Alice lädt Bobs Dokument von der bekannten URI mit einem Client, der es ihr ermöglicht, den http response header einzusehen. Si könnte beispielsweise wget benutzen (eine Windows Version gibt es ebenfalls): wget -S -O bob.html http://bob.example.net/#foo Jetzt hat Alice den response header auf dem Bildschirm und Bobs Dokument lokal auf der Platte.
  3. Alice sucht nun nach dem X-Pingback header auf dem Bildschirm, findet aber keinen.
  4. Alice öffnet nun Bobs Dokument und findet dort link rel="pingback" href="http://bob.example.net/xmlrpcserver" Wenn dies nicht vorhanden wäre, würde Bobs Blog kein Pingback unterstützen, und Alice wärde hier aufgeben.
  5. Da der Link aber vorhanden ist, erstellt Alice nun mit einem beliebigen Texteditor eine xml rpc Datei, die die sourceURI und die targetURI wie folgt enthält: ?xml version="1.0"? methodCall methodNamepingback.ping/methodName params param valuestringhttp://alice.example.org/#p123/string/value /param param valuestringhttp://bob.example.net/#foo/string/value /param /params /methodCall
  6. Anschließend sendet Alice diese Datei an Bobs Blogsystem, zum Beispiel wieder mit wget: wget --header='Content-Type: text/xml' -O response.xml\ --post-file=$XML http://bob.example.net/xmlrpcserver Replace $XML with the file name of the xml file just created.
  7. Als Ergebnis bekommt Alice eine Datei response.xml, die sie nun nach Erfolg oder Fehlercode durchsuchen kann.

Referenzen

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