{"id":912,"date":"2009-04-13T00:00:04","date_gmt":"2009-04-12T23:00:04","guid":{"rendered":"http:\/\/www.jurecuhalev.com\/blog\/?p=912"},"modified":"2009-04-13T22:01:28","modified_gmt":"2009-04-13T21:01:28","slug":"revcanonical-and-extra-burden-on-services","status":"publish","type":"post","link":"https:\/\/www.jurecuhalev.com\/blog\/revcanonical-and-extra-burden-on-services\/","title":{"rendered":"rev=”canonical” and extra burden on services"},"content":{"rendered":"

With debate about rev=”canonical<\/a>” being the next best big thing in land of Twitter<\/a> and shortening services, I wanted to throw in two extra things to consider:<\/p>\n

\n
\n
\n
\"eggs<\/a><\/dt>\n
Image by Dystopos<\/a> via Flickr<\/dd>\n<\/dl>\n<\/div>\n<\/div>\n

How can we trust the rev=”canonical” URL? Who’s burden it is to prove that they’re correct URLs. What to do with misconfigured rev=”canonical” targets?<\/p><\/blockquote>\n

The proposal<\/a> states that they should return 301 redirect<\/a>, but this means three things for service like Twitter to check:<\/p>\n

1. Hit original URL and parse HTML
\n2. Get the new URL and check if it has 301 redirect
\n3. (optional) in case 301 redirect is not there or is maybe other type of 3xx, does it go and check for original URL.<\/p>\n

What to do in case of rev=”canonical” is the same URL that was just parsed, just like <\/span>ArsTechnica<\/span><\/a> does now.<\/span> Do we say fine, lets use that long URL or we then decided on 3rd party URL shortner?<\/em> (Marko points out that they’re using correct rel= and not rev).<\/p>\n

What do you do when you can’t resolve the domain or something goes wrong in our oh-so-stable interwebs? Does HTML need to be valid or we just use regular expression to find the rev=”canonical” part?<\/p>\n

Second question is, do we really expect services to accept this extra burden?<\/p><\/blockquote>\n

Off-loading tiny url generation to 3rd part service like bit.ly<\/a> gives you an URL, but doesn’t guarantee you there’s anything behind it. You can easily shorten http:\/\/foo.foo into a bit.ly link<\/a>.<\/p>\n

This means that suddenly an operation that once took a single call to bit.ly, now takes at least a few magnitudes more CPU and network resources as pages need to be accessed, parsed and checked for validity. While this might be possible for smaller services, I highly doubt Twitter wants to implement this any time soon.<\/p>\n

Any alternatives?<\/p><\/blockquote>\n

There might be a cheat Twitter and other services could use. If we’re so afraid that we’re lose the links, it seems that they should be kept in a database under the control of the service.<\/p>\n

This doesn’t fully solve the problem of long term URL maintainance, but at least it’s under the control of the same provider who stores the original context (e.g. twitts), enabling them to give you nice exports and faster expansion together with one less (perceived) liability.<\/p>\n

Related articles by Zemanta<\/h6>\n