Trackback

This document describes the TrackBack protocol -- a framework for peer-to-peer communication and notification between web sites. The central artifact of the TrackBack protocol is an HTTP request called a "Ping" that is used to essentially communicate that "resource A is related to or linked to by resource B".

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, .

TrackBack Ping URL - The HTTP URI to which TrackBack Ping requests are POSTed. Ping - An HTTP POST request send from a client to a server for the purpose of establishing an explicit relationship between Web resources. Client - The entity sending a Ping. Server - The entity receiving the Ping. Target Resource - The Web resource to which a Ping is directed for the purpose of establishing a relationship between it and an Originating Resource. Originating Resource - A Web resource containing a reference or link to the Target Resource.

TrackBack is an application layer protocol utilizing HTTP POST requests to establish relationships between Web resources. For instance, given two domains A and B, when a resource is created on domain A that relates to or references a resource located within domain B, domain A sends an HTTP POST request to domain B using a TrackBack Ping URL provided by domain B to notify domain B of the existence of the new resource.

The entity payload of TrackBack Ping requests consist of a collection of properties expressed as name=value pairs encoded in accordance to the rules of the application/x-www-form-urlencoded media type as defined by . The Content-Type header of the HTTP POST request MUST be 'application/x-www-form-urlencoded'. Clients SHOULD transmit the character encoding of the entity payload using the charset parameter of the Content-Type header. This specification defines the following TrackBack Ping properties: title - A human readable title for the Originating Resource. excerpt - A human readable excerpt of text from the Originating Resource. url - The URL of the Originating Resource. blog_name - A human readable name for the entity to which the Originating Resource belongs. id - A permanent and universally unique Internationalized Resource Identifier, (IRI) identifying the Originating Resource. source - The URL of a resource containing the Originating Resource. Of these properties, only "url" is required. Clients MAY choose to include name=value pairs in addition to those described above. Servers SHOULD ignore any such properties that it does not understand.

Example TrackBack Ping Request

Upon successful receipt and processing of a TrackBack Ping Requests, the Server SHOULD respond with an HTTP status code of 200. Whether the Ping was successfully processed or not, the entity payload of the HTTP response MUST include a TrackBack response document as specified below. The Content-Type header for such document MUST be either 'text/xml' or 'application/xml' and SHOULD specify the character encoding of the response entity using the charset parameter.

If the Ping request was successfully processed, the 'response' element MUST either omit the 'error' error or set the content value of the 'error' element to '0'. If the Ping request was not successfully processed, the 'response' element MUST contain an 'error' element with a content value of '1' and SHOULD contain a 'message' element whose content value conveys a human-readable explanation of error.

Example Successful TrackBack Response 0 ]]>

Example Failed TrackBack Response 1 Authentication is required ]]>

Before a Client can send a TrackBack Ping to a Server, it must first identify the TrackBack Ping URL to which it send the HTTP POST request. To facilitate the discovery of the TrackBack Ping URL, Servers MAY use either of the two mechanisms described below.

Individual Web resources represented by HTML , XHTML , or Atom Syndication Format documents MAY contain a link element with a 'rel' attribute value of 'trackback', a 'type' attribute value of 'application/x-www-form-urlencoded', and an 'href' attribute specifying the Trackback Ping URL for the resource.

Example HTML TrackBack Link ]]>

Example Atom TrackBack Link ... ... ]]>

Web resources that represent multiple potential Target Resources MAY provide a single TrackBack RDF Document for each individual pingable resource. These documents are typically embedded within HTML or XHTML documents and are typically not intended to be dislayed within a Web browser. In order to prevent browsers from displaying these documents, they may be embedded within Comment markup.

--> ]]>

As an application protocol based on HTTP, the TrackBack Protocol is subject to the same security considerations discussed in . The nature of the TrackBack Protocol makes it possible for malicious clients to send undesirable Pings to a Target Resource for the purpose of establishing illegitimate links between resources in order, in part, to boost the Originating Resources search engine rankings. Such undesirable pings are known as "TrackBack Spam". The TrackBack Protocol does not specify any normative countermeasures for preventing TrackBack Spam but a number of preventative practices have emerged through the implementation of the protocol. For instance, some Servers have adopted the practice of scanning Originating Resources for legitimate links to the Target Resource. As many forms of TrackBack Spam omit such links, such practice has been demonstrated to be an effective defense. Another defensive practice that has proven effective is active moderation of the received TrackBack pings. With this approach, TrackBacks Pings are held in a temporary queue until an administrator either approves or denies the Ping. This practice effectively ensures that undesirable Pings will be filtered out during the administrative review process. Additional methods of defending against TrackBack Spam could include blocking TrackBack Pings originating from the IP addresses of known TrackBack Spammers, automatic throttling of TrackBack Pings, or the use of HTTP Authentication mechanisms.

This specification specifies the following new value for the Atom Syndication Format's Registry of Link Relations: