Page MenuHomePhabricator

Super-short URLs are formed incorrectly for articles with titles starting with a slash
Open, LowestPublic

Description

If $wgArticlePath = '/$1', a URL created from a title starting from a slash is malformed: [[/etc]] on a page in a namespace for which subpages are not enabled gives http://etc/ not http://my-server//etc as it should.

The article "/etc" is still accessible by the URL http://my-server//etc.

Tested under MW 1.25.2.

Yes, I know that such URLs are not recommended, but that is not the point.

Event Timeline

alex-mashin raised the priority of this task from to Needs Triage.
alex-mashin updated the task description. (Show Details)
alex-mashin added a subscriber: alex-mashin.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 19 2015, 11:45 PM
Aklapper triaged this task as Lowest priority.Sep 20 2015, 7:13 PM
Aklapper set Security to None.

What would be a summarized description of this bug? Editing the task summary is welcome (e.g. by adding a verb as it currently does not describe a problem). Thanks!

alex-mashin renamed this task from Super-short URLs and articles that start with a / to Super-short URLs are formed incorrectly for articles with titles starting with a slash.Sep 20 2015, 7:23 PM
alex-mashin updated the task description. (Show Details)
alex-mashin updated the task description. (Show Details)
alex-mashin updated the task description. (Show Details)Sep 20 2015, 7:28 PM
alex-mashin updated the task description. (Show Details)
alex-mashin updated the task description. (Show Details)
alex-mashin updated the task description. (Show Details)
TTO added a subscriber: TTO.Sep 21 2015, 7:14 AM

I suspect what happens here is that links to the /etc page get output as <a href="//etc">...</a>, which is then interpreted by the browser as a protocol-relative link.

What happens if you set $wgArticlePath = '/./$1'?

alex-mashin added a comment.EditedSep 21 2015, 10:42 AM


What happens if you set $wgArticlePath = '/./$1'?

In this case, MW engine forms ugly-looking but correctly working URLs, which are prettyfied by browsers (I have checked Firefox and Opera): [[/etc]] → <a href="/.//etc"> in page's source code → http://my-server//etc in browser's status bar, in the clipboard when the link is copied and in the address bar if the link is opened. But I don't know how search engines will treat such internal links.

Perhaps, leading slashes should be URL-encoded or prepended with ./ when forming a wikilink on pages in the main namespace if it does not support subpages?

For the time being, I worked around with this in LocalSettings.php:

// This is for titles starting with /: [[/etc]] → "//etc" → "/.//etc".
// Set merge_slashes off in nginx config!
$wgHooks ['GetLocalURL'] [] = function ($title, &$url, $query) {
	if (mb_substr ($title->getText (), 0, 1) === '/'
	 && $title->getNamespace () === 0
	 && !MWNamespace::hasSubpages (0 /* the same as $title->getNamespace () but faster */)
	) {
		$url = '/.' . $url;
	}
	return true;
};

Than you, @TTO, for your help.

But I think this is definitely a bug as wiki articles' titles can start with a slash and wiki URLs can contain double slashes.

And as of MW 1.26.3 and 1.27, this workaround no longer helps.