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)
 * was designed to provide an extensible base for this sort of thing. You'd just add a 'by hash' method or some such. cscott (talk) 22:32, 24 September 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)
 * Would we provide wikidumps of the MySQL table? And de-dup entries?  Are there privacy implications (you can find out if someone has already shortened a particular URL, and roughly when)?  And please consider reducing the set of characters to remove easy-to-confuse characters, since one of the points of a shortener is to work in environments where the user has to manually type in the URL. I recommend extending Special:Redirect, but cross-wiki redirects would be a New Thing. cscott (talk) 22:32, 24 September 2013 (UTC)
 * Also, I'm a little concerned with non-en wikis. For example, zhwiki uses the first component of the path to give language variant.  We should make sure that the short link for https://zh.wikipedia.org/zh-hant/User:Cscott (for example) doesn't lose any of its components. cscott (talk) 22:33, 24 September 2013 (UTC)