30

The URL for this question is currently

https://meta.stackexchange.com/questions/110407/please-add-question-and-answer-shortlinks-with-site-names-to-the-s-tk-url-shorte

which is very long. This is partially mitigated by the https://meta.stackexchange.com/q/110407 syntax, but still quite large, especially for places like http://meta.electronics.stackexchange.com/q/123456. The links to any answers will be even longer, having something like /110408#110408 appended to the URL, even if it's shortened.

Now that we have an awesome URL shortener, this can be shorter! We could reduce the short link to http://s.tk/meta/q/110407 without losing any information contained in the current shortened question URL.

Before you freak out about the nastiness of having thousands of short URLs, the opacity and durability problems of big hashmaps like the ones behind normal URL shortening services, the complexity a big network of referral IDs that can never be lost or changed, or whatever might worry you about this proposal, consider this option:

You don't have to set up a whole network of referral IDs which can be lost. You don't need a big hash map pointing to arbitrary places. Just forward the text following http://s.tk/<short site> to the destination. I'm no ASP.net wizard (in fact I've never written a line of C# in my life until this very moment), but I'm guessing (based on a Stack Overflow search) that something like the following currently resides at http://s.tk/so:

private void Page_Load(object sender, System.EventArgs e)
{
    Response.Status = "301 Moved Permanently";
    Response.AddHeader("Location","http://www.stackoverflow.com");
}

Just add two commented lines, and edit the last one:

private void Page_Load(object sender, System.EventArgs e)
{
    // Get the current URL
    string url = HttpContext.Current.Request.Url.AbsoluteUri;
    // ex. 'http://s.tk/so' or 'http://s.tk/so/q/123456'

    // Change it to the new one
    url = "http://www.stackoverflow.com" + url.Substring(14);
    // Beware the magic number! It's strlen("http://s.tk/so")

    Response.Status = "301 Moved Permanently";
    Response.AddHeader("Location", url);
}

I've proposed this with the Google Docs tool (http://s.tk/linkrequest) as requested in How do we get a new s.tk added?, but that's been silent, so I'll write it here, in public:

Please send the information after the s.tk short link to the destination page.

3
  • 7
    I agree, and /linkrequested this earlier myself. If /so goes to http://stackoverflow.com/, I would hope that /so/FOO would go to http://stackoverflow.com/FOO. It seems like the natural thing to do.
    – Jeremy
    Oct 27, 2011 at 2:45
  • http://meta.stackexchange.com/q/110407 is a valid URL to this question.
    – apaderno
    Oct 27, 2011 at 6:28
  • 5
    @kiamlaluno - I'm aware of that. From the second paragraph: This [length problem] is partially mitigated by the http://meta.stackexchange.com/q/110407 syntax. That's a valid URL, but it's not a short URL in my book. http://s.tk/meta/ is a short URL that redirects to http://meta.stackoverflow.com; I am proposing that we be allowed to tack /q/110407 onto the actual short form. Oct 27, 2011 at 12:30

1 Answer 1

5

There's no point in doing this.

The only acceptable automated use of url shorteners is for Twitter, and they're basically forcing everything through t.co these days.

Consider, http://s.tk/gaming/q/33439*; that's 26 characters, decidedly more readable than a bit.ly link but if you tweet it you'll end up with some opaque t.co link. Some clients unwrap them for you, so you see the original link... which means we'd rather tweet the actual question link so people see where the link will actually take them.

We've actually been a little down this route before, we used to wrap everything we tweeted via bit.ly (out of necessity) but stopped when Twitter started wrapping those links.

More philosophically, url shorteners are kind of evil. Not "kicking puppies" evil, but perhaps "poking poodles". It's an extra redirect (on top of one that will already happen to get the title "slug" into the URL), which can really hurt mobile users (complaints from whom actually revealed the above bit.ly problem to us) and an extra layer of indirection to trip up Google.

*This is ignoring answer links and share links (for the Booster and similar badges), both of which should embed another id or two into the url.

7
  • 8
    So, this may be a silly question, but why even set up a Stack Exchange URL shortener in the first place? Oct 27, 2011 at 19:41
  • 4
    One other place where I'd consider s.tk short URLs to be more than acceptable is all of the Stack Exchange comments and chat posts. That's what I'd use this for. Oct 27, 2011 at 19:56
  • 1
    @Chris - dev wasn't consulted, it's a PR thing. I can see some value if you're literally printing the URL on something, but if it's being generated by the site it should be a proper link. Oct 28, 2011 at 0:07
  • 1
    @KevinMontrose Ah, okay, fair enough. I can understand why PR would want vanity URLs. Oct 28, 2011 at 0:23
  • For Twitter, this isn't needed anymore, since they've done the decent thing and shorten all URLs themselves now. However, for SO comments this still is an issue.
    – sbi
    Jun 21, 2012 at 18:53
  • 4
    i don't like pasting 80 character urls in irc channels. I'd rather paste shorter ones.
    – chovy
    Sep 24, 2012 at 4:49
  • Proposal: Use an id2str conversion to build really short urls like s.tk/sobocQc where the first two chars so are reserved for the network site and bocQc is the calculation of the answer id 42277820 P.S. s.tk/so does not work anymore!
    – mgutt
    Feb 16, 2017 at 23:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .