bit.ly shouldn't attempt to shorten links that are shorter than the URL it will generate.
However in this case the error is actually in Tweet Deck. The bit.ly API can't reject short(er) urls sent to it in case you really do just want to wrap an existing short link in analytics - systems trying to read your mind and getting it wrong with no way to correct it are amazingly annoying.
So, the bit.ly API working as intended. I can't even believe that the Tweet Deck bug is malicious as URLs that are shorter than a bit.ly link are rare, and certainly not common enough to be worth complicating the UI for. There's already an 'undo shortening' button after all.
So he takes an URL shorter than the minimum bit.ly length, and uses that as evidence that URL shorteners suck? That's like saying cars and airplanes suck because they won't save you any time if you want go from your bedroom to your toilet.
Exactly. This is a non issue (non article). Who even cares? I bet a survey of Tweetdeck or Bitly would reveal that 99.something% are actually shortened and not just modified. And you have the option not to shorten URLs in Tweetdeck anyway...
Your point of view is surely valid.
Though what I get from posted article is the fact that url shorteners don't always shorten urls.
Thus proving that the philosophy behind the service is either not "to shorten urls" or simply bugged.
I can imagine an url shortener service, which actally at heart wants to shorten urls, already from first line of implementation has something like if(entered_url.length <= generated_url.length) return entered_url
I'd prefer to say example.com/a_nice_long_link rather than example.com/qQqueF especially when a single typo in the latter could take the recipient to a random site on the Internet rather than a 404 & search page.
I used it when I had to setup my iPod to download some iCal web calendar. It was autogenerated by software had as a result had a huge url - some two hundred characters I think - and I didn't what to type all that in on my iPod.
I often find myself browsing on one computer, finding the thing I was looking for -- perhaps a download link or a page I'm going to copy/paste a lot from -- and then wanting to view that page on my dev computer that's right next to me.
Yeah, I could set up Synergy or I could email myself (oops, VPN's connected, can't get to my email easily right now!), but a bit.ly bookmarklet works just fine.
> The only time I ever use URL shorteners is when I'm trying to Rick-Roll someone.
Yes, I hardly ever visit shortened URLs. It seems like a great vector for malware when you have no idea where your click will land you. The domain name, at least, and the URL structure secondarily, of the destination site give some clues as to the content. I'm not sure why this downside is not mentioned more often.
19 comments
[ 3.2 ms ] story [ 58.9 ms ] threadbit.ly shouldn't attempt to shorten links that are shorter than the URL it will generate.
However in this case the error is actually in Tweet Deck. The bit.ly API can't reject short(er) urls sent to it in case you really do just want to wrap an existing short link in analytics - systems trying to read your mind and getting it wrong with no way to correct it are amazingly annoying.
So, the bit.ly API working as intended. I can't even believe that the Tweet Deck bug is malicious as URLs that are shorter than a bit.ly link are rare, and certainly not common enough to be worth complicating the UI for. There's already an 'undo shortening' button after all.
I can imagine an url shortener service, which actally at heart wants to shorten urls, already from first line of implementation has something like if(entered_url.length <= generated_url.length) return entered_url
The only time I ever use URL shorteners is when I'm trying to Rick-Roll someone.
Seriously, what is the use case on these things?
Yeah, I could set up Synergy or I could email myself (oops, VPN's connected, can't get to my email easily right now!), but a bit.ly bookmarklet works just fine.
Yes, I hardly ever visit shortened URLs. It seems like a great vector for malware when you have no idea where your click will land you. The domain name, at least, and the URL structure secondarily, of the destination site give some clues as to the content. I'm not sure why this downside is not mentioned more often.