Specifiche Pingback

Indice:

• Introduzione.
• Definizioni.
• L’auto rilevamento del Pingaback Server.
  • Autorilevamento con header HTTP.
  • Autorilevamento con l’elemento LINK.
  • Algoritmo di autorilevazione
• L’interfaccia XML-RPC.
• Requisiti di conformitÃ? .
• Esempio.
• Referenze.

Introduzione.

Un sistema di pingback è un modo per un blog di essere avvisato quando un altro sito web inserisce un link verso un proprio documento. Il processo avviene in modo automatico, senza nessun intervento dell’autore, e puÃ?² essere rappresentato cosÃ?¬:

1. Alice pubblica un post nel suo blog. Il post che ha scritto contiene un link verso un post del blog di Bob.
2. Il sistema di blogging di Alice contatta il sistema di blogging di Bob e gli dice: “guarda, Alice ha pubblicato un post che contiene un link ad un tuo post”.
3. Poi il sistema di blogging di Bob include un link verso il post di Alice.
4. I lettori del post di Bob possono ora seguire il link al post di Alice per leggere la sua opinione.

Quindi lo scopo dei pingback è simile a quello dei trackback, la differenza principale è che nei pingback, i diversi siti web, utilizzano per comunicare il protocollo XML-RPC.

Definizioni.

source URI (URI sorgente)

L’indirizzo della risorsa che contiene il link verso il target URI.

pingback client

Il software che esegue la connessione al pingback server per informarlo del link contenuto nel source URI verso il target URI.

pingback-enabled resource (risorsa abilitata al pingback)

Un documento, un’immagine od un’altra risorsa che da indicazioni sul proprio pingback server usando uno specifico header HTTP o un elemento (X)HTML LINK.

pingback server

Il software che accetta le connessioni XML-RPC.

pingback user agent

Un sistema che funziona da pingback client e pingback server.

target URI (URI di destinazione)

La destinazione del link contenuto nel source URI. Il target URI dovrebbe essere anche una pingback-enabled resource.

L’auto rilevamento del Pingaback Server.

Sono previsti due meccanismi per l’auto rilevamento del pingback server:

• l’inserimento di un elemento (X)HTML LINK.
• l’utilizzo di un header HTTP.

Una risorsa abilitata al pingback deve fornire almeno uno dei due sistemi.

Se la risorsa abilitata al pingback è un documento XHTML o HTML, deve anche essere validato. Un client puÃ?² rifiutare un documento non valido.

Autorilevamento con header HTTP.

Una risorsa abilitata al pingback puÃ?² fornire un header X-Pingback per permettere al client l’auto rilevamento del pingback server. Per esempio una immagine PNG servita con i seguenti header dovrebbe essere abilitata al pingback:

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

Il valore dell’header X-Pingback deve essere l’URI assoluto del pingback server.

Una pagina non puÃ?² contenere più di un header X-Pingback. I documento HTML e XHTML possono includere un elemento LINK come sostituto dell’header HTTP, sebbene questa pratica sia sconsigliata. Se si includono entrambi, il valore di X-Pingaback e quello dell’elemento LINK dovrebbero essere identici. In caso di discrepanza quello di X-Pingaback deve prevalere.

È importante tenere in considerazione che alcuni pingback client non processeranno gli header HTTP a causa delle limitazioni del loro ambiente di sviluppo.

Autorilevamento con l’elemento LINK.

Una risorsa abilitata al pingback in formato HTML o XHTML puÃ?² contenere un elemento LINK in una delle seguenti due forme:

Nel caso di documento HTML

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

Nel caso di documento XHTML

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

Se usato, l’elemento link deve essere esattamente in questo modo (incluso lo spazio bianco prima dello slash [NdT, secondo il modello di espressione regolare proposto di seguito, lo spazio bianco in questione non sarebbe obbligatorio]).

Una pagina non puÃ?² contenere più di un elemento link rel="pingback" e non puÃ?² contenere nessuna altra stringa che possa essere trovata con il modello di espressione regolare descritto successivamente.

Al posto di pingback server va inserito l’URI assoluto del pingback server. Questo URI non puÃ?² includere nessuna entitÃ?  diversa da &, <, >, e ". Altri caratteri che non sarebbero validi in un documento HTML o che non potrebbero essere rappresentati nella codifica caratteri del documento, devono essere codificate usando il sistema %xx come descritto nelle [RFC2396].

Queste regole hanno lo scopo di ridurre drasticamente i requisiti d’implementazione dell’auto rilevamento del server in un pingback client.

Algoritmo di autorilevazione.

I pingback client, dato un URI sorgente ed un URI di destinazione, dovrebbero aprire l’URI di destinazione e trovare l’URI del pingback server seguendo i seguenti passi:

1. Esaminare gli header HTTP della risposta. Se è presente più di un header X-Pingback dovrebbe usare come URI del pingback server il valore del primo trovato. Se sono in grado di farlo, i client devono esaminare gli header HTTP. Se per qualche ragione gli header HTTP non sono disponibili questo punto puÃ?² essere saltato, comunque, è importante considerare che questo ne ridurrÃ?  l’utilitÃ?  delle sue applicazioni, dato che l’elemento LINK non puÃ?² essere usato per risorse diverse da un documento HTML o XHTML, e l’header HTTP è definito per sovrascrivere l’elemento LINK in caso di discrepanza.
2. Un’altra strada è cercare la prima occorrenza della seguente espressione regolare:

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

3. Se con l’espressione regolare si ricava una occorrenza, i client devono espandere le quattro entitÃ?  permesse (& per &, < per <, > per >, e " per ").

Una volta ricavato il pingback server URI, questo dovrebbe essere usato per inviare una richiesta XML-RPC come descritto di seguito.

Se non c’è nessun header X-Pingback e se l’espressione regolare non ha fornito risultati, il target URI in questione non supporta i pingback definiti in queste specifiche ed il client puÃ?² fare quello che preferisce. Comunque è RACCOMANDATO che il client non cerchi di essere più permissivo (ad esempio esaminare il codice HTML cercando elementi LINK che assomiglino a quello del pingback), perchÃ?© questo porterebbe ad avere alcuni sistemi che riconoscerebbero il server ed altri che lo ignorerebbero.

L’interfaccia XML-RPC.

I pingback client, una volta ricavato il pingback server, dovrebbero spedire al server una richiesta XML-RPC con il methodName pingback.ping e due argomenti, rispettivamente l’URI sorgente e l’URI di destinazione. [XML-RPC].

In pratica una richiesta potrebbe essere come questa:

POST /xmlrpc.php HTTP/1.0
User-Agent: The Incutio XML-RPC PHP Library
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>
<methodCall>
   <methodName>pingback.ping</methodName>
   <params>
      <param>
        <value><string>http://uri-sorgente</string></value>
      </param>
      <param>
        <value><string>http://uri-destinazione</string></value>
      </param>
   </params>
</methodCall>

Il server deve rispondere alla chiamata usando uno stringa e/o un codice di errore.

In caso di successo, la risposta deve essere una singola stringa che contenga le informazioni che il server ritiene opportune. Questa stringa serve solo per il debugging.

In caso di errore il server deve rispondere con una risposta XML-RPC di errore. Il codice di errore dovrebbe essere uno dei seguenti:

0

Codice di errore generico. Il server pu�² usare questo errore se non riesce a determinare un codice di errore appropriato.

16

L’URI sorgente non esiste.

17

L’URI sorgente non contiene un link all’URL di destinazione, e quindi non puÃ?² essere usato come sorgente.

32

L’URI di destinazione usato non esiste. Questo errore deve essere usato solo quanto il target URI non esiste, non quando puÃ?² esistere ma non è riconosciuto (vedi il prossimo errore).

33

Il target URI specificato non pu�² essere usato come target. Pu�² essere che non esista o che non sia una risorsa abilitata al pingback.

48

Il pingback è giÃ?  stato registrato.

49

Accesso negato.

50

Il server non puÃ?² comunicare con un altro server o ricevere un errore dallo stesso, e quindi non puÃ?² completare la richiesta. È un errore simile all’errore HTTP 502 Bad Gateway. Questo errore potrebbe essere usato da pingback proxy in caso di errore di comunicazione.

A questi errori vanno aggiunti i codici di errore standard [Fault Codes] che il server deve usare per segnalare errori di più alto livello.

Un esempio di risposta di errore potrebbe essere cos�¬:

<?xml version="1.0"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><int>48</int></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string>The pingback has already been registered.</string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

Il client puÃ?² ignorare le risposte del server, ma è RACCOMANDATO che non mostri all’utente la risposta in caso di successo.

Dopo aver ricevuto una richiesta, il server pu�² fare quello che vuole, comunque i seguenti passi sono RACCOMANDATI:

1. Verificare che nell’URI sorgente sia presente un link verso il target.
2. Autoverificare che il target esista e sia valido.
3. Verificare che il pingback non sia gi�  stato registrato.
4. Registrare il pingback.
5. Rigenerare la pagina del sito con le informazioni su il pingback.

Requisiti di conformit� .

Per dichiararsi conforme a queste specifiche un pingback client deve supportare l’auto rilevazione del server e deve essere in grado di inviare una chiamata XML-RPC come quella descritta in questo documento.

Un pingback server deve essere in grado di ricevere una chiamata XML-RPC e deve sempre fornire risultati conformi a quelli sopra descritti. Fornire codici di errore diversi da zero è opzionale.

Una risorsa abilitata al pingback deve avere un header HTTP X-Pingback e/o un elemento LINK per abilitare l’autorilevamento del server.

Un pingback user agent deve essere conforme a tutti i tre precedenti punti.

Esempio.

Questo è quello che avviene in modo più dettagliato tra Alice e Bob durante l’esempio descritto nell’Introduzione.

1. Alice pubblica un articolo nel suo blog. L’articolo che ha fatto include un link ad un articolo del blog di Bob. Il link dell’articolo di Alice è http://alice.example.org/#p123, mentre quello di Bob è http://bob.example.net/#foo.
2. Il sistema di blogging di Alice analizza tutti i link esterni nel suo articolo e trova http://bob.example.net/#foo.
3. Poi richiede i primi 5 kilobytes dell’articolo di Bob.
4. Cerca l’header X-Pingback, ma non lo trova.
5. Analizza la parte di documento richiesta cercando: <link rel="pingback" href="http://bob.example.net/xmlrpcserver">. Se non trova questa stringa allora il blog di Bob potrebbe non supportare i pingback ed il software di Alice dovrebbe passare al prossimo link trovato al punto 2.
6. Altrimenti, se trova il link del server, esegue la seguente chiamata XML-RPC verso http://bob.example.net/xmlrpcserver:

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

7. Il sistema di blogging di Alice ripete i passaggi dal punto 3 al punto 6 per ogni link esterno trovato nel suo articolo.

Qui finisce il lavoro di Alice. Il resto del lavoro è svolto dal blog di Bob.

1. Il blog di Bob riceve un ping dal blog di Alice (il ping spedito nel precedente punto 6) che contiene http://alice.example.org/#p123 e http://bob.example.net/#foo.
2. Il blog di Bob conferma che http://bob.example.net/#foo è un post del suo blog.
3. Richiede la pagina http://alice.example.org/#p123 e verifica il Content-Type per essere sicuro che contenga del testo.
4. Verifica che tra i contenuti ci sia un link verso http://bob.example.net/#foo (per prevenire i pingback di spam ).
5. Il blog di Bob ottiene anche altre informazioni dai contenuti di Alice, come il titolo della pagina, un estratto dei contenuti vicino al link verso il post di Bob, indicazioni sulla lingua della pagina, ecc.
6. Finalmente il blog di Bob salva il pingback nel suo database e rigenera la pagina del suo blog inserendo il pingback di Alice.

Referenze.

Pingback 1.0

Pingback 1.0, S. Langridge, I. Hickson, settembre 2002. L’ultima versione di Pingback è reperibile all’indirizzo: http://www.hixie.ch/specs/pingback/pingback.

[RFC 2396]

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. IETF, agosto 1998. La RFC 2396 è reperibile all’indirizzo http://rfc.net/rfc2396.html.

[XML-RPC]

XML-RPC Specification, D. Winer. UserLand Software, Inc, giugno 1999. Le XML-RPC Specifications sono reperibili all’indirizzo http://www.xmlrpc.com/spec.

[FaultCodes]

Specification for Fault Code Interoperability, D. Libby, et al. maggio 2001. Le Specification for Fault Code Interoperability sono reperibili all’indirizzo http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php.

post<li>

tag: HTTP, pingback, trackback, XML RPC.

post correlati:

• Introduzione al protocollo XML-RPC
• Come funzionano i TrackBack