Das ganz normale Chaos, täglich frisch auf den Tisch. Direkt aus der hintersten Provinz in die Metropolen von Groß-Blogistan.


  1. Pingback specification
  1. Pingback specification

    Wed, 09 Jan 2008 09:50:09 GMT

    Dies wird ausnamsweise auch auf englich gepostet.
    Recently i wrote a letter to Ian Hickson, the author of the pingback specification about a small point missing in that specification. Here is part of my email with his answer:
    >After the client has sent the pingback xml rpc, normally the server > would then load the file given in the sourceURI to check if the pinging > "document" is in fact related to the original article. Now what is > missing in the spec is, what mime type should that sourceURI point to? > Should it point to an html file (text/html) or to an rss feed > (application/xml or application/rss+xml)? I found several > implementations expecting html, others expecting rss, and these servers > could not parse the "wrong" document type, so sometimes pingback fails. Hm, interesting. You're right, it would have been good to specify that that should be HTML. I guess in practice servers will have to just support both RSS and HTML. :-/ I'm not really maintaining that spec anymore, though, so I won't edit it at this point. Feel free to blog about this and raise the issue to people's attention. So i'm just doing that. Let's start with a sample pingback xml file:
    ?xml version="1.0"? methodCall methodNamepingback.ping/methodName params param valuestring%SOURCEURI%/string/value /param param valuestring%TARGETURI%/string/value /param /params /methodCall
    The URI to be inserted by the pinging client (%TARGETURI%) is given by the server, as specified. The URI to be inserted for %SOURCEURI% is chosen by the pinging client. The server might just add this source URI to the blog artikle. Then there are no problems. But if the server wants to check the contents of the URI to validate (for example that it is no SPAM) then the server has to load and parse that file. Unfortunately it is not specified what exactly the server may expect: html, xhtml, rss, atom, rdf or whatever. As can be seen from Ian Hicksons answer, it was meant to be html. Out in the wild i found servers pretty legally expecting only rss. So i'd suggest an addition to the specification:
    First, all servers MUST be capable of parsing html and rss if they want to parse the file at all.
    Second the server SHOULD send an appropriate http Accept header when loading the file. It is legal to send more acceptable mime types than text/html or application/xml or application/rss+xml. It should also be possible to accept completely different mime types as for example images, sound files and so on. The server may decide to discard the pingback if it is not able to parse the source URI. Automatic content negotiation may take place.
    I try to publish a new complete specification as soon as possible.
    Die URI, die für %TARGETURI% eingesetzt wird, wird vom Server vorgegeben, wie spezifiziert. Die URI für %SOURCEURI% wird vom Client gewählt. Der Server könnte diese URI schlicht zu dem Blogartikel hinzufügen. In diesem Fall gibt es keine Probleme. Wenn der Server aber den Inhalt der URI prüfen möchte (zum Beispiel zur Spamvermeidung), dann muss er das Dokument laden und parsen. Unglücklicherweise fehlt in der Spezifikation, was für ein Format der Server dabei erwarten darf: html, xhtml, rss, atom, rdf oder was sonst. Wie aus der Antwort von Ian Hickson ersichtlich ist, war html gemeint. In der Praxis habe ich auch Server gefunden, die, völlig legal, ausschliesslich rss erwartet haben. Daher schlage ich eine Ergänzung der Spezifikation vor.
    Zunächst MUSS jeder Server html und rss parsen können, so er denn überhaupt das Dokument parsen will.
    Zweitens SOLLTE der Server einen geeigneten http Accept header senden, wenn er das Dokument lädt. Es sind weitere mime-Typen zulässig zusätzlich zu text/html, application/xml und application/rss+xml. Es sollte möglich sein, auch ganz andere mime Typen zu akzeptieren wie Bilder, Sounddateien und so weiter. Der Server kann einen Pingback ablehnen, wenn er nicht in der Lage ist, das Dokument zu parsen. Automatic content negotiation ist anwendbar.
    Ich werde versuchen, eine neue komplette Spezifikation so schnell wie möglich zu veröffentlichen.