Talk:Requests for comment/URL shortener

lilurl
Stand on the shoulders of giants (or maybe in this case, not giants). Use lilurl, which currently powers ur1.ca and others. --MarkTraceur (talk) 02:11, 14 November 2012 (UTC)


 * You don't need to be a giant to write 400 lines of code. The coding style is not at a standard we would accept for MediaWiki. Concurrent inserts are not supported and will result in key conflict errors. The symbol alphabet is short compared to most URL shorteners (36), I'm not sure if that's deliberate. The input URL is not validated, so it's possible to have it output a Location header with spaces, nulls, etc. There's no localisation.


 * I think the best way for us to implement this would be as a MediaWiki extension. The UI could take advantage of the usual MW facilities, and the redirect could be done with a rewrite rule to a special page, like how we do Wikidata redirects. If it's part of MediaWiki, then it will need very little maintenance. -- Tim Starling (talk) 00:58, 17 July 2013 (UTC)

Extension:ShortURL
I think it's better than lilurl, but it is limited to redirecting to canonical URLs of articles, it can't redirect to an arbitrary URL, and it can't redirect to a special page. Like lilurl, it is limited to base 36. -- Tim Starling (talk) 01:27, 17 July 2013 (UTC)

Tim's implementation suggestion

 * A MediaWiki extension.
 * Have a special page UI similar to lilurl etc.: ask the user to submit a long URL, get a small URL back
 * Accept only valid input URLs under WMF-controlled domains, to avoid the maintenance overhead which would come from widespread non-WMF use.
 * Also provide an API module, so that JS can fetch and display a small URL for the current page.
 * Host the redirects at a short domain name, to be purchased.
 * Use a rewrite rule to map short URLs to special page requests, for redirection.
 * Implement using a MySQL table with an autoincrement ID. The ID is converted to a larger base for use in the short URL, similar to Extension:ShortURL.
 * Use base 62 (uppercase, lowercase, digits) or higher.

The idea is to avoid any conceivable use case for external URL shorteners. External URL shorteners are a privacy and reliability concern, and so we should replace them with something in-house. It may be true that many uses of URL shorteners are inappropriate; it may even be that they are entirely redundant and should be discouraged in the strongest terms. However, discouraging them on this RFC is not going to stop them from being used. It's a small project, there are clear benefits, so we should just do it.

RFC authors, please integrate this implementation suggestion with the RFC page if you agree with it. -- Tim Starling (talk) 01:27, 17 July 2013 (UTC)