The URL shortener situation is out of control
41–50 of 79 posts
Re: The URL shortener situation is out of control
#42Earlier quoted context omitted.
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
#43Is the ridiculously long ThisURLShortenerSituationIsOfficiallyOutOfControl.aspx url part of the rant against short urls?
I'm no SEO guru, but isn't the recommended behavior to create a URL that matches the title of the blog post? I've seen these "post title" URLs with increasing frequency over the past few years.
Re: The URL shortener situation is out of control
#44Earlier quoted context omitted.
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.
That's no longer a URL shortening service, that's a campaign redirection service. Just serve the appropriate content, rather than relying on redirects.
Directly serving the content while possible is not what my client wants. They want to go from their short URL to the longer full domain one.
Re: The URL shortener situation is out of control
#45Earlier quoted context omitted.
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 ver…
Re: The URL shortener situation is out of control
#46Earlier 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…
1.) The browser can offer the ability to (right click) and shorten a URL or lengthen it. A HTTP standard would provide this mechanism.
3.) The would not require multiple redirects because everyone should ask the domain. If the URL is already shortened then there is not need to shorten again. - service like bit.ly, goo.gl can provides services to: 1.) Actually shorten, statistics...
Re: The URL shortener situation is out of control
#47We 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.)
That could break a lot of bad-yet-benign code.
Re: The URL shortener situation is out of control
#48> 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 if you think about this for a few seconds, you'd find out that if you were able to create such a solution, you've have destroyed some information theory laws.
Re: The URL shortener situation is out of control
#49This is classic "Tragedy of the commons" behavior where each individual group with a link shortener is benefited by encouraging and enforcing its usage (ability to kill malicious links easily, user tracking, etc) I'm not sure if this can be resolved until users are educated sufficiently on the long-term adverse effects of link shortening services (link rot, privacy concerns, slow/broken redirects, etc). For change to…
It wouldn't solve it completely, but it'd kill the 7 redirects thing.
Re: The URL shortener situation is out of control
#50I think the most practical solution to this, requiring only a change in practice and not in standard, would be for link shorteners to start doing HEAD requests on the urls they shorten and unwrap it to make their shortened link canonically correct if it results in a permanent redirect. Yeah, there are things that might have some problems with this, but they're things that are probably somewhat abusive to the 301 stat…