Webmention is a simple way to notify any URL when you link to it on your site. From the receiver's perspective, it's a way to request notifications when other sites link to it.

Author's Note

This section is non-normative.

This specification was contributed to the W3C from the IndieWebCamp community. More history and evolution of Webmention can be found on the IndieWebCamp wiki.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document was published by the Social Web Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-socialweb@w3.org (subscribe, archives). All comments are welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

1. Introduction

At a basic level, a Webmention is a notification that one URL links to another.

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 [RFC2119].

1.1 Overview

This section is non-normative.

A typical Webmention flow is as follows:

  1. Alice posts some interesting content on her site (which is set up to receive Webmentions).
  2. Bob sees this content and comments about it on his site, linking back to Alice's original post.
  3. Using Webmention, Bob's publishing software automatically notifies Alice's server that her post has been linked to by the URL of Bob's post.
  4. Alice's publishing software verifies that Bob's post actually contains a link to her post and then includes this information on her site.

1.2 Protocol Summary

This section is non-normative.

  1. User Aaron posts a blog post on his blog
  2. User Barnaby writes post on his blog that links to Aaron's post.
  3. After publishing the post (i.e. it has a URL), Barnaby's server notices this link as part of the publishing process
  4. Barnaby's server does Webmention discovery on Aaron's post to find its Webmention endpoint (if not found, process stops)
  5. Barnaby's server sends a Webmention to Aaron's post's Webmention endpoint with
    • source set to Barnaby's post's permalink
    • target set to Aaron's post's permalink.
  6. Aaron's server receives the Webmention
  7. Aaron's server verifies that target in the Webmention is a valid permalink on Aaron's blog (if not, processing stops)
  8. Aaron's server verifies that the source (when retrieved, after following redirects [FETCH]) in the Webmention contains a hyperlink to the target (if not, processing stops)

2. Webmention Protocol

2.1 Sending Webmentions

2.1.1 Sender discovers receiver Webmention endpoint

The sender MUST fetch the target URL and check for an HTTP Link header [RFC5988] with rel="webmention", or a <link> or <a> element with rel="webmention". If more than one of these is present, the first HTTP Link header takes precedence, followed by the first <link> element, and finally the first <a> element. Clients MUST support all three options and fall back in this order.

The endpoint MAY be a relative URL, in which case the sender MUST resolve it relative to the target URL according to the [URL] specification.

Senders MAY initially make an HTTP HEAD request [RFC2616] to check for the Link header before making a GET request.

This specification uses the link rel registry as defined by [HTML5] for both HTML and HTTP link relations.

Example 1
GET /post-by-aaron HTTP/1.1
Host: aaronpk.example
HTTP/1.1 200 OK
Link: <http://aaronpk.example/webmention-endpoint>; rel="webmention"

<link href="http://aaronpk.example/webmention-endpoint" rel="webmention" />
<a href="http://aaronpk.example/webmention-endpoint" rel="webmention">webmention</a>

2.1.2 Sender notifies receiver

The sender MUST post x-www-form-urlencoded [HTML5] source and target parameters to the Webmention endpoint, where source is the URL of the sender's page containing a link, and target is the URL of the page being linked to.

The Webmention endpoint will validate and process the request, and return an HTTP status code [RFC2616]. Most often, 202 Accepted or 201 Created will be returned, indicating that the request is queued and being processed asynchronously to prevent DoS attacks. If the response code is 201, the Location header will include a URL that can be used to monitor the status of the request.

Any 2xx response code MUST be considered a success.

Example 2
POST /webmention-endpoint HTTP/1.1
Host: aaronpk.example
Content-Type: application/x-www-form-urlencoded


HTTP/1.1 202 Accepted

2.2 Receiving Webmentions

Upon receipt of a POST request containing the source and target parameters, the receiver SHOULD verify the parameters (see Request Verification below) and then SHOULD queue and process the request asynchronously, prevent DoS attacks. There are three possible responses to the request, depending on how the receiver processes it.

If the receiver creates a status page which the sender can use to check the status, the receiver MUST reply with an HTTP 201 Created response with a Location header pointing to the status URL. The response body MAY contain content, in which case a human readable response is recommended.

Example 3
HTTP/1.1 201 Created
Location: http://aaronpk.example/webmention/DEhB9Jme
Content-type: text/plain

The Webmention is being processed. You can check on its status here: http://aaronpk.example/webmention/DEhB9Jme

If the receiver processes the request asynchronously but does not return a status URL, the receiver MUST reply with an HTTP 202 Accepted response. The response body MAY contain content, in which case a human readable response is recommended.

Example 4
HTTP/1.1 202 Accepted
Content-type: text/plain

The Webmention is being processed

If the receiver chooses to process the request and perform the verification step synchronously (not recommended), it MUST respond with a 200 OK status on success.

2.2.1 Request Verification

The receiver MUST check that source and target are valid URLs [URL] and are of schemes that are supported by the receiver. (Most commonly this means checking that the source and target schemes are http or https).

The receiver SHOULD check that target is a valid resource that it can accept Webmentions for. This check SHOULD happen synchronously to reject invalid Webmentions before more in-depth verification begins.

Note that a target URL may contain a fragment identifier, and if the receiver limits which URLs can receive Webmentions, it SHOULD remove the fragment before checking if the URL is supported.

2.2.2 Webmention Verification

Webmention verification SHOULD be handled asynchronously to prevent DoS attacks.

If the receiver is going to use the Webmention in some way, (displaying it as a comment on a post, incrementing a "like" counter, notifying the author of a post), then it MUST perform an HTTP GET request on source, and follow any HTTP redirects (up to a self-imposed limit such as 20) and confirm that it actually links to the target.

The receiver SHOULD use per-media-type rules to determine whether the source document links to the target URL. For example, in an [HTML5] document, the receiver should look for <a href="*">, <img href="*">, <video src="*"> and other similar links. In a [JSON] document, the receiver should look for properties whose values are an exact match for the URL. If the document is plain text, the receiver should look for the URL by searching for the string. Other content types may be handled at the implementer's discretion. The source document MUST have an exact match of the target URL provided in order for it to be considered a valid link.

At this point, the receiver MAY publish content from this Webmention on the target page or other pages, along with any other data it picks up from the source. For example, the receiver may display the contents of the source as a comment on the post.

2.2.3 Error Responses

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

Possible sender-related errors that can be returned synchronously before making a GET request to the source:

  • Specified target URL not found.
  • Specified target URL does not accept Webmentions.
  • source URL was malformed or is not a supported URL scheme (e.g. a mailto: link)

Possible sender-related errors that can occur after fetching the contents of the source URL:

  • source URL not found.
  • source URL does not contain a link to the target URL.

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

2.2.4 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.
    • When a Webmention implementation does support updating (AKA a "Webmention update implementation"), MUST support updating data from properties of the primary object of the source. (e.g. properties of the [h-entry] of the page).
      • A Webmention update implementation MAY support updating data from children, or other descendant objects of the primary object (e.g. a comment h-entry inside the h-entry of the page). If an implementation does support this, it MUST support it according to the [Salmention] extension specification (AKA a "Salmention implementation").
  • If it received a 410 Gone status code on step 2 (performing a GET request on source), or received a 200 OK status code and does not find a link to target on source, it SHOULD delete the existing Webmention, or mark it as deleted.
  • Processing Webmentions SHOULD be idempotent. For example, receiving multiple Webmentions for the same source and target with no content changes should not show as multiple replies.

3. Security Considerations

3.1 Preventing Abuse

3.2 Limits on GET requests

The Webmention protocol relies on the sender making a GET (or HEAD) request to discover the receiver's endpoint, followed by the receiver making a GET request to the sender's web page to verify the link. This means a sender can cause a receiver to make GET requests to arbitrary URLs, opening up a potential DoS vector.

Receivers SHOULD place limits on the amount of data and time they spend fetching unverified source URLs. For example, if a source URL doesn't respond within 5 seconds, it can treat that as a failure. Similarly, the receiver can fetch only the first 1mb of the page, since any reasonably HTML or JSON page will be smaller than that.

4. IANA Considerations

The link relation type below has been registered by IANA per Section 6.2.1 of [RFC5988]:

Relation Name:
Identifies a target URI that supports the Webmention protocol. This allows clients that mention a resource in some form of publishing process to contact that endpoint and inform it that this resource has been mentioned.
W3C Webmention Specification (http://www.w3.org/TR/webmention/)
This is a similar "Linkback" mechanism to the ones of Refback, Trackback, and Pingback. It uses a different protocol, though, and thus should be discoverable through its own link relation type.

A. Extensions

This section is non-normative.

The following Webmention Extension Specifications have 2+ interoperable implementations live on the web and are thus listed here:

A.1 Vouch

The [Vouch] protocol is an anti-spam extension to Webmention.

A.2 Salmention

The [Salmention] protocol is an extension to Webmention to propagate comments and other interactions upstream.

B. Resources

This section is non-normative.

C. Articles

This section is non-normative.

You can find a list of articles about Webmention on the IndieWebCamp wiki.

D. Implementations

This section is non-normative.

D.1 Libraries

D.1.1 Sending

D.1.2 Endpoint Discovery

  • link_rel_parser - PHP http_rels($h) & head_http_rels($url) - HTTP header string parser for RFC5988 Link: rels (including X-Pingback) & function to curl a HEAD request and parse it all in one.
  • phpish/link_header - PHP Link header (RFC 5988) parser
  • PEAR: HTTP2 - PHP Link header (RFC 5988) parser (documentation)
  • ronkyuu - Python client library and command-line tools

D.1.3 Receiving

D.1.4 Parsing

D.2 Plugins

D.3 Tools

D.4 Services

E. Acknowledgements

The editor wishes to thank Sandeep Shetty for contributing the original draft of the Webmention specification.

Additionally, the editor wishes to thank the IndieWebCamp community and other implementers for their support, encouragement and enthusiasm, including but not limited to: Amy Guy, Benjamin Roberts, Ben Werdmüller, Dave Wilkinson, Rob Sanderson, and Tantek Çelik.

F. Change Log

This section is non-normative.

F.1 Changes from 12 January 2016 FPWD to this version

This section lists changes from the 12 January 2016 FPWD to this Working Draft

G. References

G.1 Normative references

Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October 2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
R. Fielding; J. Gettys; J. Mogul; H. Frystyk; L. Masinter; P. Leach; T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. June 1999. Draft Standard. URL: https://tools.ietf.org/html/rfc2616
M. Nottingham. Web Linking. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5988
Ben Roberts; Tantek Çelik. Salmention. Living Specification. URL: http://indiewebcamp.com/Salmention
Anne van Kesteren. URL. Living Specification. URL: https://url.spec.whatwg.org/

G.2 Informative references

D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). July 2006. Informational. URL: https://tools.ietf.org/html/rfc4627
Aaron Parecki; Tantek Çelik. Vouch. Living Specification. URL: http://indiewebcamp.com/Vouch
Tantek Çelik. h-entry. Living Specification. URL: http://microformats.org/wiki/h-entry