Jens Oliver Meiert

Pingback 1.0 (Ian Hickson & Stuart Langridge)

Originalversion:
http://www.hixie.ch/­specs/pingback/pingback
Übersetzer:
Jens Oliver Meiert, meiert.com
Datum der Übersetzung:
7. November 2004 (↻ 7. Februar 2007)

Bei diesem Dokument handelt es sich um eine deutsche Übersetzung, die urheberrechtlich geschĂŒtzt ist; bitte beachten Sie auch etwaige Hinweise des Originaldokuments. Das in allen ZweifelsfĂ€llen maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an den Übersetzer. Kommentare des Übersetzers, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht des Übersetzers. Sie sind kein Bestandteil des Ursprungsdokuments.

Pingback 1.0

Diese Version:
http://www.hixie.ch/specs/pingback/pingback-1.0
Aktuelle Version:
http://www.hixie.ch/specs/pingback/pingback
Vorherige Versionen:
http://www.hixie.ch/specs/pingback/pingback-0.9.3
http://www.hixie.ch/specs/pingback/pingback-0.9.2
http://www.hixie.ch/specs/pingback/pingback-0.9.1
http://www.hixie.ch/specs/pingback/pingback-0.9
http://www.kryogenix.org/writings/tech/pingback
http://www.kryogenix.org/days/000138.cas
Herausgeber:
Stuart Langridge <sil@kryogenix.org>
Ian Hickson <ian@hixie.ch>

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:

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:

Inhaltsverzeichnis


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

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

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 &amp;, &lt;, &gt; und &quot; 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 (&amp; fĂŒr &, &lt; fĂŒr <, &gt; fĂŒr > und &quot; 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:

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 Fehlercodes 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 Fehlercodes (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 Fehlercodes, 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.

Fehler entdeckt? E-Mail an jens@meiert.com.

Du bist hier: Startseite → Publikationen → Pingback 1.0 (Ian Hickson & Stuart Langridge)

Stand: 7. Februar 2007

Professionelle Frontend-Entwickler produzieren valides HTML und CSS.