> 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.
Why do we need a technical solution. My understanding is that the author is arguing for a change in how URL shorteners are being used, not a technical change making this impossible. The problem is that once a technology exists, it will be abused. Sometimes this abuse is just a clever and useful hack, and sometimes it is annoying and anti-usable.
If I remember correctly, there was an old (very old) project with reversible links called Project Xanadu.
if my sketchy memory serves me, it was based around using a currency and updatable links. Along with that, the idea was that you could also share segments of movies and music with the hyperlink system.
I'm pretty sure it died a pitiful death due to it being completely secret until after HTTP got ingrained.
I looked at it before, and it was, indeed, neat. But, I'm not sure that a project that spent 30 years in development before an initial release can really be said to have "died".
I think the other issue is that these aren't being used as URL shorteners any more (in the sense they were when they were used for Twitter's 140 character limit). They are tracking URLs, gathering data about you at each hop.
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 into the server software that integrate 3rd parties.
4.) Each domain could create their own shortened URL domains and mask it in a better way.
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.
> 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.
That assumes that every user gets the same "long" URL for a particular "short" URL (and that every 30x corresponds to a short-to-long redirect). It falls down where a URL depends on geolocation or time sensitivity.
The URL should be under the full control of the domain.
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...
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.