News

Welcome to End Point’s blog

On URL Shorteners and Selena FLOSSing

I just read an interesting article on the various downsides to URL shorteners. Let's not break the Internet that way. I found the article on Hacker News, which I'd forgotten about -- this is the Hacker News at Y Combinator, not the good ol' but long-dead Hacker News Network formerly at hackernews.com.

In other news, our very own Selena Deckelmann appears in moving pictures at FLOSS Weekly 64! I haven't even had time to watch it all yet.

6 comments:

At the other end of the URL Shorteners debate: why do sites, particularly e-commerce it seems, think that *longer* is *better*? I just went to post a link to an item I thought would be of interest to a friend, and found the link to the flypage was 248 characters long. This seems absurd to me.

I don't think a lot of it, upon first consideration. It's probably better than nothing, but it's hard to see how it would ever be preferable to using the canonical URL wherever possible. It seems to be an attempt to solve a problem that doesn't need to be there in the first place.

Where are these short URLs really needed? Just SMS and Twitter? Most everywhere else can handle a real URL.

Maybe Twitter could solve the problem on their own by using the full canonical URL when displayed on their website, and only showing the shortened URL when passing the message to a length-challenged target.

"Where are these short URLs really needed? Just SMS and Twitter? Most everywhere else can handle a real URL."

Actually, I still run across a lot of email clients that can't handle a line-wrapped URL. When sending a link to your Great-Aunt, you want something she can just click on. I use URL shorteners when posting links to (non-technical) email lists because I'm sure everyone will be able to access them.

It makes good points and is good to consider, but it can be a reductio ad absurdum if it leads one to conclude we should return to binary protocols packed to save every bit, use short and cryptic identifier names, etc. The advantages won over the years as we've moved to more plain text-based protocols shouldn't be forgotten.

The article also only mentions cookies in passing, but the number of cookies a modern website can accumulate is striking, and they can each be very long. They're sent out on every browser request, and are never gzip-compressed, greatly adding to overall bandwidth. Application servers should be checked that they're not needlessly re-setting cookies that were already set, which adds to uncompressed response size.