Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The URL shortener situation is out of control

hanselman.com

Post reply on HN
Print view View original

31–40 of 79 posts

Re: The URL shortener situation is out of control

#31

Post by X-Istence »

codyb wrote: post #14
userbinator wrote: post #11

This is propagated by people not really understanding URLs and blindly reposting links that have already been wrapped in a URL shortener through services that wrap them in another one. Whenever I repost links, I repost only the URL of the final page, stripping off anything unnecessary. Sadly, the trend of browsers hiding URLs or pieces of them is not helping the situation either. I don't think this can be solved tech…

Could a URL wrapper service follow a URL through its redirects only wrap the final address? I'm not a networking expert, but it seems viable enough to me. Shoot out a GET request, wrap the final address with your shortener. Cut out the middlemen. It's an idea. It might fail at scale. And might not be feasible.

Downside is that if I use an URL shortening service that allows me to change where you are headed after the fact (for example after 1000 hits, go to a new page instead) then you've just broken that functionality.

Re: The URL shortener situation is out of control

#32

Post by a3n »

> What do you think?

I think URL un-shortening should be done in the browser, on URLs that were shortened according to a standard hashing method, so your browser can tell you where the URL will go.

Shortening sevices are ridiculous and dangerous.

Re: The URL shortener situation is out of control

#33

Post by palakchokshi »

bbuffone wrote: post #12
baddox wrote: post #2

> Redirects are being abused and I don't see any work happening in HTTP 2.0 to change it. I agree that this is an unfortunate pattern, but what exactly could the HTTP spec do to change it? The only thing I can think of is limiting the number of chained redirects, although I don't see browsers implementing that if longer chains are even remotely common.

If the HTTP spec added 2 new VERBS (SHORT, LONG) as a method of shortening and elongating URLs then many things could be done. 1.) The browser could pro-actively lengthening the URL and the same way the server can respond 302/301 now the browser could cache this. 2.) The server could hand-back the final long URL with out needing to redirect the URL multiple times 3.) We could create services that can be integrated in…

1) The browser doesn't know the long URL so how can it proactively lengthen it? 2) The server might not know the long URL since all that t.co knows about is the slate.me URL and that only knows about the slate.tribal URL and it only knows the goog.le url and so on and so forth. So this would not be possible unless it was only 1 hop.

3)I am assuming the services you want to integrate into the server software will resolve the shortened URL into a long one or vice versa but in case there are multiple redirects the services would still face the latency of redirects.

Re: The URL shortener situation is out of control

#34

Post by dragonwriter »

palakchokshi wrote: post #33
bbuffone wrote: post #12

Earlier quoted context omitted.

If the HTTP spec added 2 new VERBS (SHORT, LONG) as a method of shortening and elongating URLs then many things could be done. 1.) The browser could pro-actively lengthening the URL and the same way the server can respond 302/301 now the browser could cache this. 2.) The server could hand-back the final long URL with out needing to redirect the URL multiple times 3.) We could create services that can be integrated in…

1) The browser doesn't know the long URL so how can it proactively lengthen it? 2) The server might not know the long URL since all that t.co knows about is the slate.me URL and that only knows about the slate.tribal URL and it only knows the goog.le url and so on and so forth. So this would not be possible unless it was only 1 hop. 3)I am assuming the services you want to integrate into the server software will reso…

> The server might not know the long URL since all that t.co knows about is the slate.me URL

The server at t.co could send a request (HEAD works) to slate.me, and follow up any redirects it gets to resolve the final URL. (This could be done just by following until no more redirects, or only sending requests to known URL shorteners -- there's advantages and disadvantages to both) -- and you don't need any new HTTP verbs to do it.

Re: The URL shortener situation is out of control

#35

Post by stormbrew »

mmahemoff wrote: post #18

That's really unfortunate. And it's not just performance, it really messes around with OS-level URL handling protocols like Android intents (and possibly FB's app links and iOS's new Extensibility). I recently found this happening with Twitter's Android app. The user sees a link to player.fm and thinks it will open the native Player FM app if they have it installed, since it's registered to handle that URL pattern. B…

> I recently found this happening with Twitter's Android app. The user sees a link to player.fm and thinks it will open the native Player FM app if they have it installed, since it's registered to handle that URL pattern. But instead, the OS offers web browsers and Twitter as ways to open the link, because it's not really a player.fm link as presented to the user, but a t.co link. If the user then chooses a browser, the browser immediately redirects to the correct URL, which then pulls up the intents menu again.

You don't even have to go that far. Just click on a youtube link. First it'll ask if you want the www.youtube.com url to play in a browser or the app (which sucks), then it'll redirect to m.youtube.com and ask you again.

Only reason I haven't set it as my permanent choice is because I still hold out some shred of hope that the youtube app will be able to play an entire video without stopping for 2 seconds every 3 some day in the future.

Re: The URL shortener situation is out of control

#36

Post by thrill »

nostromo wrote: post #9

We could put a stop to marketing redirects tomorrow if we didn't allow redirects to set cookies. (Or perhaps only allowed a cookie if the redirect was served by the same domain as the target domain.)

Seems logical - only allow the endpoint to set the cookie.

Re: The URL shortener situation is out of control

#37

Post by X-Istence »

Lifescape wrote: post #22

I couldn't find anything that would output something similar to the redirects image shown in this post, so wrote a small script in node to do that. It looks like this: http://cl.ly/image/3T3e462G1C3d Here's the script: https://gist.github.com/akenn/7ca7e99a51c3a4abc049 Speaking of, what software did this guy use? Is there a bash script that's better than what I wrote?

Here is a simple script that uses curl/awk to print the same sort of information:

https://gist.github.com/bertjwregeer/12ae691e5c285f334a36

No need to use Node.

Re: The URL shortener situation is out of control

#38

Post by dragonwriter »

a3n wrote: post #32

> What do you think? I think URL un-shortening should be done in the browser, on URLs that were shortened according to a standard hashing method, so your browser can tell you where the URL will go. Shortening sevices are ridiculous and dangerous.

>I think URL un-shortening should be done in the browser, on URLs that were shortened according to a standard hashing method

Hashing, by definition, is non-reversible. So if you use a hashing method as your shortening system, you'll have a fingerprint from which the actual destination is unrecoverable.

> Shortening sevices are ridiculous and dangerous.

Right, and there is no reason to use them in any situation where the target is a browser, anyway. It makes sense to use a shortening service if you are going to be sending a URL in an SMS message, but if its going to a browser, there's no reason not to use the full URL. So, really, a server based system that will send message both as SMS and to regular browser users should support a shortener and use it only when sending SMS.

Re: The URL shortener situation is out of control

#40

Post by narsil »

nostromo wrote: post #9

We could put a stop to marketing redirects tomorrow if we didn't allow redirects to set cookies. (Or perhaps only allowed a cookie if the redirect was served by the same domain as the target domain.)

This would result in marketers returning 200 responses to set the cookie and render a page with javascript that sets `window.location` instead, which would be even slower.
Post reply on HN