Webmention 0.2 (RC1)

Webmention is a simple way to automatically notify any URL when you link to it on your site. From the receivers perpective, it's a way to request notification when other sites link to it.

It’s a modern alternative to Pingback and other forms of Linkback.

Note that the latest, most up-to-date specification is located on the IndieWebCamp wiki.

Versions

Latest Version:

http://indiewebcamp.com/webmention

Previous Versions:

version 0.1

Editors

Sandeep Shetty (sandeep.shetty@gmail.com)

Contributors

Aaron Parecki (aaron@parecki.com)
Barnaby Walters

License

CC0+OWFa

To the extent possible under law, the editors and contributors have waived all copyright and related or neighboring rights to this work. In addition, as of 27 September 2013, the editors and contributors have made this specification available under the Open Web Foundation Agreement Version 1.0.

Introduction

Here's a typical webmention flow:

Alice posts some interesting content on her site (which is setup to receive webmentions).
Bob sees this content and comments about it on his site, linking back to Alice's original post.
Using webmention, Bob's publishing software automatically notifies Alice's server that her post has been linked to along with the URL to Bob's post.
Alice's publishing software verifies that Bob's post actually contains a link to her post and then includes this information on her site.

Protocol Flow

Sender discovers Receiver Endpoint

GET /post-by-alice HTTP/1.1
Host: alice.host

HTTP/1.1 200 OK
Link: <http://alice.host/webmention-endpoint>; rel="webmention"

<html>
<head>
...
<link href="http://alice.host/webmention-endpoint" rel="webmention" />
...
</head>
<body>
....
<a href="http://alice.host/webmention-endpoint" rel="webmention" />
...
</body>
</html>

The webmention endpoint is advertised in the HTTP Link header or a <link> or <a> element with rel="webmention". If more than one of these is present, the HTTP Link header takes precedence, followed by the <link> element, and finally the <a> element. Clients MUST support all three options and fall back in this order.

Sender Notifies Receiver

POST /webmention-endpoint HTTP/1.1
Host: alice.host
Content-Type: application/x-www-url-form-encoded

source=http://bob.host/post-by-bob&
target=http://alice.host/post-by-alice

HTTP/1.1 202 Accepted

http://alice.host/webmentions/222

202 Accepted is the recommended status code to return indicating that the request SHOULD be queued and processed asynchronously to prevent DoS attacks. The response body SHOULD include a URL that can be used to monitor the status of the request.

If you choose to process the request and perform the verification step synchronously, you can respond with a 200 OK status on success.

See Error Responses for what to do when the webmention is not successful.

Verification

The receiver SHOULD check that target is a valid resource belonging to it and that it accepts webmentions.
The receiver SHOULD perform a HTTP GET request on source to confirm that it actually links to target (note that the receiver will need to check the Content-Type of the entity returned by source to make sure it is a textual response).

At this point the receiver can choose to publish information about this webmention along with any other data it picks up from source.

Error Responses

Sender Error

If the webmention was not successful because of something the sender did, you SHOULD return a 400 Bad Request status code and MAY include a description of the error in the response body.

Possible sender related errors (from the Pingback specification):

Source URL not found.
Specified target URL not found.
Source URL does not contain a link to the target URL.
Specified target URL does not accept webmentions.

Receiver Error

If the webmention was not successful because of an error on the receivers server, it SHOULD return a 500 Internal Server Error status code and MAY include a description of the error in the response body.

Updating existing webmentions

If receiver had received a webmention in the past with the same source and target then,

If both the verification steps are successful, it SHOULD update any existing data it picked from source for the existing webmention.
If it received a 410 on step 2 (performing a GET request on source) or does not find a link to target on source, it SHOULD delete the existing webmention.

Preventing Abuse

The verification process SHOULD be queued and processed asynchronously to prevent DDoS attacks.
Receivers SHOULD moderate Webmentions, and if a link is displayed back to the source, SHOULD link to source with rel="nofollow" to prevent spam.
Receivers MAY periodically re-verify webmentions and update them.
If a receiver chooses to publish data it picks up from source, it should ensure that the data is encoded and/or filtered to prevent XSS and CSRF attacks.

Implementations

See IMPLEMENTATIONS

TODO

Prevention of DDoS
- Malicious attacker could send webmentions to a lot of sites with Alice's site as source which will result in a DDoS on Alice's site.
- See this discussion about Refback. tl;dr: Hixie says "it's already pretty trivial to cause a server to get a lot of GETs, that's not a particularly interesting security issue imho".
backcompat with v0.1 by also supporting rel="http://webmention.org"?

Let's collaborate

Feel free to file an issue if you have feedback/questions/suggestions.

converspace / webmention

readme