Slashdot Log In
Can rev="canonical" Replace URL-Shortening Services?
Posted by
Soulskill
on Sun Apr 12, 2009 02:40 PM
from the snds-lk-a-pln dept.
from the snds-lk-a-pln dept.
Chris Shiflett writes "There's a new proposal ('URL shortening that doesn't hurt the Internet') floating around for using rev="canonical" to help put a stop to the URL-shortening madness. In order to avoid the great linkrot apocalypse, we can opt to specify short URLs for our own pages, so that compliant services (adoption is still low, because the idea is pretty fresh) will use our short URLs instead of TinyURL.com (or some other third-party alternative) replacements."
Related Stories
[+]
Search: Google Unveils goo.gl URL Shortening Service 242 comments
eldavojohn writes "The Sultan of Search is unveiling a new service (currently only available for Google Toolbar and Feedburner) that will tackle a very old problem usually solved by bit.ly or tinyurl — URL shortening. Now, we've heard cries for sanity to prevent potential issues (like what if tr.im had shut down and broken millions of links?) but with one of the goliaths of the industry jumping in the ring it looks like URL shortening is here to stay. And a quick note for people who enjoy privacy, goo.gl explicitly states: 'Please note that Google may choose to publicly display aggregate and non-personally identifiable statistics about particular shortened links, such as the number of end user clicks.' You didn't think Google was going to sit back and let bit.ly harvest juicy data on 2.1 billion links that were clicked in November without trying to corner some of that action to make their ad suggestions more accurate, did you?" Google's shortening service is called Goo.gl.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
but will they be cute? (Score:5, Funny)
What value are these new URLs if they aren't cute?!? [socuteurl.com]
Seth
Re:but will they be cute? (Score:4, Funny)
Parent
Re: (Score:3, Funny)
This is why rel="cute" should be introduced. Then we will be able to avoid the so-called "cute linkrot" which, despite its name, will be ugly.
Re: (Score:3, Insightful)
I'd also like to propose rel="evil" (for shock URLs and Microsoft) rel="nsfw" and rel="rickroll".
Re: (Score:3, Informative)
Parent posted goatse-link. I suggest you don't click it unless you are into that.
WTF? (Score:4, Insightful)
I didn't understand a single word of the submission, and I used to teach Web design. Is it too much to ask submitters to define terms they use?
Re:WTF? (Score:5, Informative)
This whole url shortening shit started to pick up steam few days ago when Digg introduced Diggbar - a hybrid of frame and url-shortening that framed other sites and did not display the proper site address. John Gruber went nuts and modified his blog to redirect users to a special page [digg.com]. Then he blogged for 2 days non-stop how to make diggbar go away. Since he's widely read around the web everyone started chiming in with their opinions on the general idea of url shortening services and how it hurts or helps the web.
Nerd bullshit. And not the good kind.
Parent
It was not the shortening at issue though (Score:4, Informative)
It wasn't even the Digg Bar exactly. Gruber didn't like it because of the obvious reasons (breaks bookmarks, history, hides the site, etc) but mainly because the DiggBar was turned on by default for all users. Other sites have things like the Diggbar, but no-one really complained about them because users had to turn them on by default.
If he alone had not liked it you would not have seen the rush to block it from all quarters. I as a user despised it myself, and am happy to see all framing mechanisms die a horrible death.
Shortening services that use a redirect, he and others have no issue with.
Parent
a better idea (Score:5, Funny)
how about we just kill all twitter users instead?
Re:a better idea (Score:5, Funny)
Parent
Re: (Score:3, Interesting)
how about we just kill all twitter users instead?
Funny? No, you deserve +5 Interesting at least.
My wife signed up for that crap and at age 37 I've got to cope with her phone going off multiple times during Easter diner and her sharing with my family that Kevin Smith (of Clerks fame) can't decide if he should dry-hump his wife's leg or just rub one out because it's 3am she's asleep and he's stoned and horny.
Shorten links to avoid messes like this: (Score:5, Insightful)
http://developers.slashdot.org/comments.pl?threshold=2&mode=thread&commentsort=3&sid=1196477 [slashdot.org]
URL shortened, of course (Score:5, Interesting)
On the Twitter /. feed, this of course shows as:
slashdot [twitter.com] Can rev="canonical" Replace URL-Shortening Services? http://tinyurl.com/c3j4n8 [tinyurl.com]
P.S. Now if you want a really short URL, try http://tinyarro.ws/ [tinyarro.ws] (no affiliation; just impressed by the idea)
It's a phone problem (Score:3, Interesting)
This is a phone-related problem. The basic problem is that URLs are being sent to devices that don't cut, paste, and bookmark. This is only an issue if you have to type the URL manually.
Maybe what's needed are smarter Twitter clients.
Alternative Solution: Implement it Right? (Score:5, Insightful)
There's all this talk of URL shortening services - whether third-party, or in-house implementation.
The question here is this: Why are the URLs so long to begin with?
Why does it have to be:
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
A full title in the URL is, IMHO, a very inefficient idea. The excuses I've heard are:
Search Engine Optimizations (better performance when keywords are in the URL)
Okay, I can't argue that some search engines do stuff like that. But shouldn't the TITLE or META tags have more bearing on this than how ridiculously long the URL is?
"The URL has meaning, so you know what you're clicking", Context, etc.
I suppose that when I see a URL like
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
as opposed to something like
http://example.org/blog/526
I would have a slightly better idea of the article's content before clicking on it. But then again, I can't really say that I've decided against clicking on a link just because of the link URL. I would, instead, decide whether I'd want to visit the link by its link text/description.
So <a href="http://example.org/blog/526">blog on link shortening</a> would still have the same effect on me as a long URL IMO. If it were bookmarked, the same rules would apply.
Hell, if I were handed an obfuscated shortened URL without context, I'd know even less of what I was getting myself into.
I think the proper solution is to just stop making ridiculously long URLs to begin with, so we don't have to rely on obfuscation/hashing/shortening to accommodate services that have character limit restrictions. And we'd save bandwidth too [slashdot.org], apparently. Win-win?
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
The biggest problem with long URLs would be in e-mails as they usually get word wrapped. So when they click on it may not properly cut/paste the full URL into the default browser.
Every try cut and pasting this LONG URL from e-mail to the browser if you're using a small monitor, i.e. laptop?
http://maps.live.com/default.aspx?v=2&FORM=LMLTCP&cp=37.827041~-122.422875&style=h&lvl=18&tilt=-90&dir=0&alt=-1000&phx=0&phy=0&phscl=1&encType=1 [live.com]
Re: (Score:3, Interesting)
I've actually been thinking about switching to longer URLs for my own blog. I'm currently using numerical filenames, because it seemed simpler at the time, but the number is basically meaningless to any human looking at the URL. Links within my site always have title tags, but every once in awhile I'll send somebody the URL to one of my blog entries, and it would be nice to see at a glance which entry it is (in case you've read it already).
To hell with Twitter. :-P
It doesn't solve the problem. (Score:3, Insightful)
Here's the thing: it's not just the path that is the problem, it's also the domain name. You can shorten "/blog/2009/apr/save-the-internet-with-rev-canonical" to "/abc123", but if your domain name is something plus-sized like "rickosborne.org" or worse ... how much have you really gained?
It's a little helpful, but not really. What you've done is remove the little bit of semantic meaning from the link, all in the name of being able to ego surf easier. Huzzah.
I prefer hugeurl (Score:5, Funny)
"Because bigger is better, right?" http://www.hugeurl.com/ [hugeurl.com]
Well, I call for long URLs (Score:5, Insightful)
All this short URL stuff sounds like some phishing scam if you ask me. Short cryptic URLs obviously exist to make me transpose a couple of letters or numbers and end up at some fake bank site. No, give me large detailed URLs so I can see those dead giveaways like pid=poor_sucker&sid=steal_credit_card_info !
Short URLs indeed... no thank you Nigerian scammers... I won't be transferring any large sums today!
On a serious note, why is this news exactly?
URL mapping is the answer (Score:5, Interesting)
Unfortunately, it's not yet an integral part of web frameworks that I have seen. So I am adding it in a new web site I'm building. It means I have to add the feature to the web server.
It works like this. Every part of the web site code that builds URLs for the same site passes them first through the mapping logic. This basically builds an SHA1 checksum of the canonicalized URL string. Then it looks up the string in a fast database (I'll be using Berkeley DB for this). If it's already there, and is the same URL, it generates a new URL that references the checksum. If it was a different URL, it notifies me that it found an SHA1 collision. If not already there, it adds it. The original URL is thus replaced with the mapping URL.
Code added to the web server will be designed to detect checksum URLs. If it looks like one, it looks it up in the database to get the original URL, and proceeds with the request using that URL. Original URLs would still be processed as usual, in case they leak out, or are intentionally made to bypass the mapping for special purposes. Basically it's like a tiny URL service, but integrated without the need to do a redirect.
One thing I am looking at doing is shortening even these URLs, even though they should be short enough already. But this raises the chance for a collision to the point I'll need to add logic to deal with it. How I would do that is similar to a hash data structure collision, but by expanding on the SHA1 checksum by adding back digits that were removed to shorten it.
External URLs to other sites can be done the same way. This does add the extra redirection. I could limit the use of this only to long external links, since this being a web interface, should handle long external links OK. It could be an option.
Re:URL mapping is the answer (Score:4, Insightful)
...why?
Really, I have no idea what the point is. Here's a TFA URL:
http://joshua.schachter.org/2009/04/on-url-shorteners.html [schachter.org]
Here's what yours might look like:
http://joshua.schachter.org/89dfaf0834055017af95b8cbb8b440819c3db49a [schachter.org]
Congratulations, it's longer. What's the gain?
Parent
A Few Responses (Score:5, Interesting)
A couple of good questions I have seen, and my best attempt to answer them:
1. Don't you mean rel? No, I mean rev. It indicates a reverse link.
2. Why not make your URLs short in the first place? I happen to like my URLs and have made them as short as I want them. They're only too long in some very specific use cases, like Twitter. I could just complain about Twitter, or I could support an idea that makes URL shortening suck less. I chose the latter.
Thanks for reading, and please do feel free to criticize whatever you think is wrong with this idea. I'd like a way to indicate a preferred short URL for my own stuff, and this seems like a pretty good way to do it that makes sense semantically and is easy to implement. For an ongoing discussion about adding an HTTP header to do the same thing (so that only a HEAD request is required), read here:
http://shiflett.org/blog/2009/apr/a-rev-canonical-http-header [shiflett.org]
Re: (Score:3, Insightful)
It's a very mildly useful feature, but it's unnecessary bloat.
First and foremost: It's extra strain on (my) servers. Let's say this becomes an accepted standard and we start having every blogging/forum/comment system doing these lookups to find a smaller url. This means that any time a document on one of my servers is linked to, there's going to be at least one request sent for it so your system can check if a shorter url has been specified. So, now I'm serving up extra data for a feature I won't likely use
DNS Overload ? (Score:3, Insightful)
And if you click on them rarely the delay would be neglible, cos you only use them rarely
Plus this, interesting as it may be, still does not solve how to get a long url into a Tweet... it does not matter if Twitter can go look up the small URL on its own
Reasonable URLs ! (Score:3, Insightful)
Why do so many URLs look like RDBMs queries? Has someone been sold a bill-of-goods?
As for shorter URLs, they become much shorter minus the DB cruft. And then all it takes is a modicum of logic to form some durable system.
Some people cannot avoid flavor-of-the-month. Those people should not be making decisions with any sort of permanence or continuity.
i blame (Score:3, Insightful)
digg
Re: (Score:3, Funny)
Re:"Great link apocolypse" WAT? (Score:5, Informative)
short summary: everyone should adopt this NewTechnology(tm) because it will make twitter work better
1. If everyone uses it
2. if twitter implements support for it
of course it's pretty much useless for everyone else
Parent
Re:"Great link apocolypse" WAT? (Score:5, Informative)
This story should be tagged Twitter.
This guy seems to be focusing on the meaningful identifier aspect of URL shortening for use in a space limited context - without actually confining his suggestion to use in that sort of environment.
He puts forth other reasons for using this method such as control over the persistence of the shortened URL, but that doesn't make a whole lot of sense to me... and then he goes back to mentioning Twitter.
Parent
Solving the wrong problem (Score:5, Insightful)
Yes, TinyURL hasn't killed anyone. BUT... any attempt to fix this is entirely missing the point anyway. From the article:
If they fix twitter to support links with proper labels or tag contents --- Oh, I don't know, like HTML has supported from the very beginning --- then there wouldn't be a problem.
Don't work around the bugs, fix the bugs. Links are designed for machines, the higher-level marked up text is for people.
Parent
Re:Solving the wrong problem (Score:5, Funny)
But then you're going to have the problem solved instead of opening up a new can of worms with lots of jobs and neverending problems to solve. Intelligence is bad for the economy.
Parent
Re: (Score:3, Informative)
Erm... mobile phone texting is still called SMS. GSM designates the whole mobile communication standard, which also includes being able to launch a web browser on the phone and follow HTML links.
Re: (Score:3, Insightful)
If they fix twitter to support links with proper labels or tag contents --- Oh, I don't know, like HTML has supported from the very beginning --- then there wouldn't be a problem.
So you're proposing we don't fix the entire internet so a pointless little social service doesn't have to bugfix? Blasphemy!
Re:"Great link apocolypse" WAT? (Score:5, Funny)
From tinyurl:
Copyright © 2002-2009 Gilby Productions. All rights reserved.
(2009 - 2002) < 11+
Parent
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Re:sorry but I dont get... (Score:5, Funny)
somesite.org/wiki/index/cool_tips/code/perl/hello_world.php
That's just wrong.
Parent
Re: (Score:3, Insightful)
Yes, it looks hideously long. It also works fine, it's clickable, I really don't get the big deal.
Re: (Score:3, Informative)
Arbitrary (Score:5, Informative)
Parent
Re:Arbitrary (Score:5, Funny)
Your mom is an aggregation and redistribution tool. And she certainly didn't limit herself to 140 characters.
Parent
Re:Arbitrary (Score:5, Informative)
There's no technical reason restricting Twitter from allowing 140 rather than 160 characters, unless there's an issue I am not aware of (perhaps one or more major mobile networks are broken and only allow 140 characters rather than 140 bytes?).
20 are reserved for the user name. The co-founder mentioned this during his interview [colbertnation.com] on The Colbert nation.
Parent
Re:Arbitrary (Score:4, Insightful)
And even 140 bytes is not the limit, since you can use multipart SMS to send longer messages transparently. Though I suppose that might be undesirable on US carriers that double-dip by charging to receive as well as to send.
Parent
Re:I have an easier solution: (Score:5, Interesting)
How about Twitter just stops arbitrarily limiting characters. Go by word count, perhaps?
I know some avid twitter users, and the majority of them apparently use the idiotic SMS message system to 'tweet' each other all throughout the day on their phones. Twitter can't abandon the 140-character limit for this reason.
For the record, I am against anything that keeps the SMS system relevant in this day and age. It should have been abandoned long ago in favor of standard data packets on the internet, rather than control packets on a proprietary wireless system. There's no good reason to keep this system alive when it either forces you to pay $X per month for it, or pay $.15 per 140 characters when one of your idiot friends 'texts' you. There's no way (that I know of) to force incoming SMS to route through GPRS, so you are hit with SMS fees even when you already pay for unlimited data. It also invites spam that you actually DO pay for, quite literally, and from which the wireless carrier profits as well. It should be illegal for the carrier to charge you for incoming SMS messages. Anyone who agrees with me should call their congressperson to protest this policy and call their wireless carrier to block all SMS messages.
Parent
Re:I have an easier solution: (Score:5, Insightful)
LOL! Only in America, the free market bastion of the world, do you have to pay for incoming texts.
Parent
Re:I have an easier solution: (Score:4, Informative)
1999 called, it wants its charges back.
People pay for SMS in your country? Here even pay and go plans have unlimited SMS bundles.
And I can't even parse this statement.. "or pay $.15 per 140 characters when one of your idiot friends 'texts' you"
How can your friends make you pay for SMS? Do you have some way of sending bills over it or something?
Parent
Re:I have an easier solution: (Score:4, Informative)
US wireless carriers charge on both ends -- both the receiver AND the sender will pay the 15 cents per message, assuming neither one of them has an unlimited plan. I think this charge used to be 10 cents, but was raised to 15 cents last year. Or maybe it was 15 cents and was raised to 20 cents. I have no idea, but either way it is terrible. I think plans are typically $5/month for 200 'texts' or $15/month for unlimited.
And don't even get me started on MMS messages. I received my first MMS spam the other day. My first thought was "ooh, nice tits", but my second thought was "$#%&, I probably just got charged $3.00 for this spam!"
Parent
Re: (Score:3, Interesting)
idontthinkthatwillworkverywell.