Last modified: 2011-03-13 18:06:07 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8254 - Urlencoded slashes not accepted as slashes in URLs
Urlencoded slashes not accepted as slashes in URLs
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-12-14 01:33 UTC by Will Pittenger
Modified: 2011-03-13 18:06 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Will Pittenger 2006-12-14 01:33:50 UTC
Existing description and conversation at [[Wikipedia:Wikipedia:Village pump
(technical)#Shortcut string bug]].

Copied from there.

Firefox lets you make a shortcut string (like "wp") search Wikipedia and other
sites.  However, it turns '/' into "%2F".  Wikipedia doesn't handle that
correctly like it does when Firefox replaces ':' with a similar sequence.  Is
this fixable or do we have to wait for a MediaWiki update? -[[User:Will
Pittenger|Will Pittenger]] 06:11, 12 December 2006 (UTC)
:In namespaces with subpages disabled, '%2F' should probably be accepted as an
alias for '/'.  You could [[Mediazilla:|open a bug report]] if you like.
—[[User:Simetrical|Simetrical]] ([[User
talk:Simetrical|talk]] • [[Special:Contributions/Simetrical|contribs]])
01:53, 13 December 2006 (UTC)
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-14 04:00:21 UTC
I guess for sanity it might be best to do this for *all* pages, in fact.  Or
none.  Does anyone have an opinion?  It would seem to be the standards-y thing
to do.  Harder to read, of course, but it doesn't need to be more than an alias.
 The main issue would of course be if anyone was clever enough to make a page
already with a literal "%2F" in it, but that seems to give an outright 404 (see

Would this just require a preprocessing variable modification in index.php, or
would that be ugly?  We don't really need links, etc. to normalize this way, we
just have to make sure they can't contain the string literally (which it doesn't
look like they can right now).  Input URLs are the only things that could
usefully work this way.
Comment 2 Will Pittenger 2006-12-14 05:02:45 UTC
I have to disagree with the "enhancement" label.  The problem interfers with the
basic functionality.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-14 05:21:38 UTC
No, it does not.  Basic functionality does not include correct interfacing with
every conceivable third-party program, or even every popular third-party
program.  If Firefox isn't flexible enough to handle MediaWiki's format, then it
would be *good* for us to adjust MediaWiki to better interface with Firefox, but
it's not a *bug* if we don't.  Bugs are only present when unintended behavior
occurs; when intended but undesirable behavior occurs, that's an enhancement
Comment 4 Rob Church 2006-12-14 08:19:43 UTC
Meh, it's a moot point, to be honest; I'd class it as a minor bug. Each has his
own priorities. :)
Comment 5 Brion Vibber 2006-12-14 10:38:13 UTC
This is actually a low-level issue with Apache; it seems rather unhappy when
passed %2F as part of a path and always spits back a 404.

It's rumored this is shifty security reasons; see for example:$20da1a30$bb431b09@sashimi%3E

We really, *really* don't want to maintain custom patches to Apache again, so
we're not likely to change it on our end. (But if Apache changes the behavior in
a future version that we upgrade to, we'll be happy to take it.)

This can be worked around on the shortcutter's end by using a long-form url,
where the title appears in the query string:

or better yet:

[the latter has the benefit of redirecting to the target article if it exists
and performing a search if it doesn't exist exactly as written]

Note You need to log in before you can comment on or make changes to this bug.