Specifying rev="canonical" With HTTP
It looks like there’s a lot of momentum behind rev="canonical" now—and all built up within the span of about forty-eight hours. So, while I disagree with the use of “canonical” for semantic reasons and rev for the potential of mass misunderstanding and improper implementation, I think I’ll bite the bullet on this one for now, but time will tell what the community ultimately decides.
So, I’ve decided to eat my own dog food. Like Simon Willison, I bought my own short URL, and now all blog posts on my site include a link tag that covers all the bases similar to the following:
<link rev="canonical" rel="alternate shorter" href="http://brtny.me/382" />
And all without any special WordPress plugin. For the ID, I’m simply using the WordPress post ID, which means that, if I change to another blogging tool in the future, I will need to maintain my indexes. Note that I’ve implemented it with both the popular rev="canonical" and my preferred rel="alternate shorter".
Chris Shiflett posts about the need for an HTTP header. I think this is also a good idea, for the same reasons he mentions. Chris’s original recommendation is for an X-Rev-Canonical header, but Stephen Paul Weber mentions the Link header. I think the Link header is the right way to go about this, since it offers an HTTP analogue of the HTML link element.
Link is an IETF proposal by Mark Nottingham that is still in the Internet-Draft stage, going through the IETF process for standardization, but it’s current, which is a good thing. If the community chooses to use it, though, it’s interesting to note that that it states:
Applications that don’t merit a registered relation type may use an extension relation type. An extension relation type is a URI that, when dereferenced, SHOULD yield a document describing that relation type.
This means that one should not simply put “canonical” as the value for rev. Instead, it would be more proper to use something like “http://revcanonical.appspot.com/#canonical” until “canonical” is accepted as a registered IANA relation type. I wonder if the same is technically true of the rel and rev attributes in HTML.
For now, I’ve decided to cover all bases in my HTTP headers, as well, and you can see this by making a HEAD request to any blog post on my website, as seen in the following:
HEAD /archives/summarizing-my-revcanonical-argument/ HTTP/1.1
Host: benramsey.com
HTTP/1.1 200 OK
Date: Sun, 12 Apr 2009 05:24:34 GMT
Link: <http://brtny.me/382>; rev="http://revcanonical.appspot.com/#canonical"; rel="alternate http://revcanonical.appspot.com/#shorter"
X-Rev-Canonical: http://brtny.me/382
Content-Type: text/html; charset=utf-8
10 Comments
I've updated my Shorter Links WordPress plugin to do the same as this and put it up on the WordPress Plugin Directory: http://wordpress.org/extend...
Regards,
Rob...
Why I like rev instead of rel (quoted from my comment on Marco's post):
I like the simplicity of rel="canonical" (forward link) and rev="canonical" (reverse link) indicating the same relationship in opposite directions.
I'm going to update my post to suggest Link instead of X-Rev-Canonical, but I want to make sure we're proposing the best syntax first.
Chris: I'm also finding myself liking the reverse link relationship for the simplicity in the reasoning you mention here, but I still think it lacks semantic meaning. Why is this particular reverse link important to the canonical URL? Perhaps a combination of
rev="canonical"andrel="short"(or "shorter" or "short-url") provides the necessary balance?I like the idea of using both rev="canonical" and rel="short", but I can't think of a reason we'll ever want to refer to a reverse-canonical relationship for any other reason. Maybe someone will answer your question on Twitter with a good use case.
I updated my header recommendation to use the following:
Link: <http://tr.im/revheader>; rev=canonicalAs I've just been explaining to Ben on Twitter, getting it wrong (e.g. rel instead of rev) could permanently knock a site off its perch.
I too like rel="short" but some people thought it was like an abstract - a "short" version of the content... fair enough so I changed to shortcut. Turns out that's scorched earth courtesy Microsoft's "shortcut icon" but rel="shortlink" is not.
I can't think of a single reason *not* to use rel="shortlink" but all the other proposals (including my own) have varying degrees of deficiencies.
Sam
I vote for rel=shortlink
avoids rel/rev minefield, doesn't twist canonical. avoids url/uri debate. doesn't sound like short content or alternate format. doesn't conflict with favicons.
Ok so when are you guys going to admit (as above) that rel=shortlink is the best option?
You don't even have to lose your bragging rights and by rejecting short_url et al you save a bunch of associated confusion for implementors and consumers. Plus it's being pushed through the usual standards process (and thus far hasn't been repeatedly shot down like rev=canonical).
Sam
I'm not sure who you mean by "you guys," since I was against the use of
rev="canonical"from the beginning.I never knew this was about bragging rights or who came up with the best option? Did I miss something?
Here is another rev=canoncial user case (for mobile url):
User: "Hey document your canonical url is huge, plus I would be interested in a mobile version if you have one.. can you give me a list of some urls that your canonical url represents?"
Doc: "sure here are some rev=canonical urls"
User: "Hey sweet you have one with rel='shorturl mobile' too that's freaking amazing, you rock!"
Doc: "w/e"
-----
Also the rev=canonical http header is very good, but I would argue using the rel=canonical http header is going to be equally important so that user agents can verify a rev=canonical without retrieving the html document.
I vote for rel="shortlink" too. Got a nice ring to it. :)