Page MenuHomePhabricator

URL to pagenames with special characters fail
Closed, DuplicatePublic


when using the /wiki/<pagename> URL format, adding parameters (such as ?redirect=no) fails when the pagename includes special characters, like '?'. This occurs even when the special character is correctly URL-encoded. For example: follows the redirect to, as expected. (%3f is the url-encoded question mark character, of course) does *not* follow the redirect to; it remains at the Statistical test redirect, which is again expected.

However, *does* follow the redirect to, which is *not* expected. This is despite the fact that the first question mark is correctly URL-encoded. The final URL that we end up at appears in the browser bar as

Similarly, also incorrectly follows the redirect to User:Writ_Keeper/sandbox; the final URL there ends up as

It would seem that the URL is being decoded before the URL parameters are deciphered.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 15 2016, 1:15 AM

I would say this is functioning as intended all /wiki urls are in the short url form. Short urls do not handle any URL params. index.php is the correct access point for URLs that need params passed.

Fair enough, I suppose--I was surprised that redirect=no worked with the short form at all--but then, does that make the fact that it *does* work a bug in itself?

Beaten to the punch, but ditto them for me (well, not ve, but the others). It seems inconsistent to accept all others while rejecting redirect= in some cases. The preferred use case would be the ability to add an arbitrary query to a "pretty" URL.

@Unready: this bug actually applies to all URL parameters, not just redirect, given a page name with a question mark in it. For example:; this should take you to the history of the page [[User:Writ Keeper/sandbox?sandbox]], but instead it just ignores the url params and follows the redirect to [[User:Writ Keeper/sandbox]].

I appreciate Betacommand's point that these URL parameters shouldn't necessarily be valid for shortened urls, but one way or another, I would expect the user experience to be consistent; either always accept url params or never accept them. That we sometimes parse and use them and sometimes don't seems like a bug to me, regardless of which of those two is the expected behavior.

Ottomata added a subscriber: Ottomata.

Pretty sure there is no operations action item here, so removing tag.

This is a misconfiguration of Wikipedia's short URLs. Correctly configured MediaWiki does not exhibit this issue, I can't reproduce locally. Sounds like Operations to me. Should it be under some different project than Wikimedia-Apache-configuration?

@matmarex, perhaps, but what I'm reading is that folks think that MW should handle short URLs with query params consistently, which isn't operations. Not sure though.

MediaWiki already does it consistently and correctly, but it can't if it doesn't have access to the unmangled URL. Something in our server setup mangles the URLs irrecoverably, as described in parent task T132629.

Should this be merged into the parent task then?

Maybe? I guess it's a special case of that. Do whatever makes it easier for you folks to get it fixed :)

Ha, I'm not sure it'll help get it fixed, but it will help with ticket proliferation :)