Solving the URL shortening problem #twitter #tweet
I don’t understand why url expansion after url shortening is such an issue that it needs to be implemented for each service separately. It relies on the same protocol HTTP and should be easy to reliably reverse this. Almost all url shortening services rely on 3xx redirection to forward the request using the Location header.
Using the example of the short URL for this post “http://wp.me/phhhb-ul“:
HEAD /phhhb-ul HTTP/1.1
HOST: wp.meHTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 20 Apr 2010 18:22:53 GMT
Content-Type: text/html
Connection: close
Location: http://webhat.wordpress.com/?p=1881
Content-Length: 0
Specifically 301 is used as search engines – such as Google, Yahoo! and Bing – will index the real address rather than the shortened address. Naturally this can be done by a twitter client too.
A url can be put into this script which recursively checks the url. Example run:
$ php http.php http://bit.ly/b0Y2ds
Connect to: bit.ly (128.121.254.201)
Redirection to: http://wp.me/phhhb-ul
Connect to: wp.me (76.74.254.123)
Redirection to: http://webhat.wordpress.com/?p=1881
Connect to: webhat.wordpress.com (76.74.255.123)
Redirection to: http://specialbrands.net/?p=1881
Connect to: specialbrands.net (72.233.2.58)
True URL: http://specialbrands.net/?p=1881
Quite simple really.
