[palakchokshi]

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.

[dragonwriter]

> 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.

[garethadams]

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.

[dragonwriter]

The alternative I presented of only follow redirects from known URL shorteners addresses pretty much all of that.

[bbuffone]

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...