4 ms·
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 a
by mmahemoff 12y ago
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. 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.
7 redirects could potentially be 7 popup menus for the user to navigate through.
The OS could pre-emptively follow redirects, but that would of course introduce considerable latency since normally the menu is presented without any call being made at all. Maybe the best solution for OSs is to present the menu immediately but still make the call in the background, so the menu could be updated if a redirect happens.
"I don't see any work happening in HTTP 2.0 to change it."
Probably the best HTML standard for dealing with it is the "ping" attribute which allows a way for servers to be notified of a click without actually redirecting. However, that's HTML and not HTTP, and these days, apps are more popular HTTP clients than browsers, and apps don't manually bother to implement things like that.
So there are probably things that could be done with the standard. Perhaps using some distributed lookup table to ensure at most 1 redirect (by caching the redirect sequence and returning it with the first request). That does ignore any personalisation that goes on, but generally these should be permanent redirects without personalisation anyway.
- stormbrew 12y ago> 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.
- Groxx 12y agoFor Android at least, I've been using this and I'm pretty happy with it: https://play.google.com/store/apps/details?id=com.teaandtoys.unshorten https://play.google.com/store/apps/details?id=com.teaandtoys... It usually works, and when it does it's nice to fix the idiotic Twitter-android-app behavior.
- AndrewDucker 12y agoThank you - I've just installed this, and it's great!
- alttab 12y agoPrefetching the URL will trash analytics, which is why most of this is really done. Its not like the short URLs are easier to copy/paste, or remember.
- PeterisP 12y agoIf user convenience requires trashing server analytics, then server analytics should be trashed. Possibly even deliberately - enabling that by default automated way in commonly used products, so that this tracking becomes ineffective and useless, and there's no more motivation to insert these artifical layers of redirection.