Earlier quoted context omitted.
1- Periods (.) don't do anything after a domain (ie www.weebly.com.), but they are useful for preventing the browsers from redirecting to http://www.to.com/ 2- The real domain we're looking at: "to" -- no "suffix" attached (TLD: top-level domain ) 3- The .to registry added an A-record for the "to" domain, which resolves correctly. [Edit: Looks like .cm does this too: ;; ANSWER SECTION: cm. 86400 IN A 195.24.205.60]
Does this mean we should expect http://com./ http://net./ etc?
http://to/ World's Shortest URL Shortener
41–50 of 150 posts
Re: http://to/ World's Shortest URL Shortener
#42Earlier quoted context omitted.
yeah, got root level on the tld .. how did they manage that..
When it comes to national TLDs and how a company can have this level of access... I don't want to know...
Re: http://to/ World's Shortest URL Shortener
#43Re: http://to/ World's Shortest URL Shortener
#44Earlier quoted context omitted.
Does this mean we should expect http://com./ http://net./ etc?
Didn't CNet used to use http://com./ ?
Re: http://to/ World's Shortest URL Shortener
#45The fascination with url shorteners is really worrying and useless. Can we get past this fad?
Indeed. They're a solution to a problem that doesn't exist.
Which URL would you rather paste in an email for readability's sake:
http://maps.google.com/maps?f=d&source=s_d&saddr=Oak...
or
In context, the recipient should have no problem anticipating the URL's end point (i.e., you probably just wrote something like, "here are some directions to my house:"), but using the shortened URL makes the email much more readable and prevents any potential screwy scrolling issues that might be caused by an ultra unwieldy URL borking their email software.
That's just one non-microblogging use case for one site that spits out very long dynamic URLs -- there are many use cases for many sites.
TinyURL, et. al. certainly did (and continue to) solve a problem, imho. And they've become even more useful for microblogging sites like Twitter, on which character limit constraints (which essentially defines that type of service) require that URLs be shortened.
[EDIT: I know HN auto truncated that Google Maps URL, but it is a 355 characters long -- and most email software (my use case) wouldn't auto truncate the URL in the same way. So readability would be negatively affected for the recipient by using the long URL instead of the short one.]
Re: http://to/ World's Shortest URL Shortener
#46I wrote a program to find the shortest URL. Enjoy! #!/usr/bin/perl # use WWW::Mechanize; die "usage: $0 " unless @ARGV; $name = 'a'; $m = WWW::Mechanize->new; while (1) { print "Trying http://to./$name\n"; $m->post('http://to./', { url => $ARGV[0], name => $name, 'Witz that URL!' => 'Witz that URL!' }); unless ($m->content =~ /sorry/) { print "You got http://to./$name\n"; exit(0); } $name++; }
Re: http://to/ World's Shortest URL Shortener
#47Re: http://to/ World's Shortest URL Shortener
#48Earlier quoted context omitted.
Indeed. They're a solution to a problem that doesn't exist.
I disagree with that statement. Even before the rise of microblogging, URL shorteners were helpful in certain situations. Which URL would you rather paste in an email for readability's sake: http://maps.google.com/maps?f=d&source=s_d&saddr=Oak... or http://tr.im/Gw8B In context, the recipient should have no problem anticipating the URL's end point (i.e., you probably just wrote something like, "here are some directio…
What I would normally do is something like this " Check out my map here [1] " and at the end put "[1] http...", that way a giant ten page url doesn't interfere with the message, yet I don't have to shorten it either. If I think the precipitant won't understand what I mean, I'd put more details in, eg [1 below]
The ONLY place where I'd consider using a url shortener is printed material, since its easier to type in by hand than a giant url, but this has the same dead link problem, especially if printed in magazines.
Re: http://to/ World's Shortest URL Shortener
#49Succeeded, but sadly http://to./ rewrote it to http://index.php instead.
Re: http://to/ World's Shortest URL Shortener
#50Earlier quoted context omitted.
I disagree with that statement. Even before the rise of microblogging, URL shorteners were helpful in certain situations. Which URL would you rather paste in an email for readability's sake: http://maps.google.com/maps?f=d&source=s_d&saddr=Oak... or http://tr.im/Gw8B In context, the recipient should have no problem anticipating the URL's end point (i.e., you probably just wrote something like, "here are some directio…
The former. It shows the reader not only where I'm sending them, but even gives them an idea of what to expect, not to mention the whole dead links problem that will inevitably occur when these sights finally go down. What I would normally do is something like this " Check out my map here [1] " and at the end put "[1] http...", that way a giant ten page url doesn't interfere with the message, yet I don't have to shor…
I'm also still not sold on the dead link problem for two reasons.
1. You're already relying on one site (in this case Google) not to go down or change its dynamic URL patterns. Certainly adding another layer increases the chances of a dead link, but any time you link to something on the web you're taking a risk of sending someone to an error page.
2. Most instances in which you'd use a short URL -- such as email -- are for instant communication in which the recipient is likely to visit that link in the next day or two. In other words, you wouldn't link to a short URL in the body of your web page or blog (something with more permanence on which you want to be sure the link works months or even years from now), but for email or Twitter messages, which are generally fleeting and timely, that matters less. As long as the link works right now then all is good. If the person visiting the links wants to save it for later, they'll more than likely bookmark it, cutting the shortener out of the loop anyway.