Last modified: 2013-07-30 19:05:20 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 10473 - impossible to list allpages or prefixindex for pages starting with . or ..
impossible to list allpages or prefixindex for pages starting with . or ..
Status: NEW
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Low trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
http://fr.wikipedia.org/w/index.php?t...
:
: 52010 (view as bug list)
Depends on:
Blocks: 17094
  Show dependency treegraph
 
Reported: 2007-07-05 20:16 UTC by Darkoneko
Modified: 2013-07-30 19:05 UTC (History)
2 users (show)

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


Attachments

Description Darkoneko 2007-07-05 20:16:17 UTC
in at least Special:Allpages and Special:prefixindex, it is impossible to search for "all the pages starting with '.' " or '..' strangely enough, it works correctly with 3 or more points.

Any idea of what causes this behaviour ?
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-05 21:03:43 UTC
I suspect Apache is trying to cleverly interpret that as a directory or something.  [[Special:Prefixindex/..]] just flat-out redirects to /wiki/.  I don't know why it would try to do anything like that with query parameters, though.  Pretty peculiar.
Comment 2 Brion Vibber 2007-07-05 21:14:32 UTC
Special:Allpages tries to normalize the prefix by making a title object out of it; however '.' and '..' by themselves are illegal titles (to avoid those path problems).

The result is that the prefix / starting-point request is ignored, leading to this bug.

A fix might be to add a partial-name-validation routine of some sort, or.... something. :P :)
Comment 3 Brion Vibber 2008-12-28 21:27:37 UTC
Adjusting summary to clarify that this is prefixindex/allpages issue, not special:search issue.
Comment 4 Roan Kattouw 2009-01-07 13:57:22 UTC
(In reply to comment #2)
> Special:Allpages tries to normalize the prefix by making a title object out of
> it; however '.' and '..' by themselves are illegal titles (to avoid those path
> problems).
> 
> The result is that the prefix / starting-point request is ignored, leading to
> this bug.
> 
> A fix might be to add a partial-name-validation routine of some sort, or....
> something. :P :)
> 

The list=allpages API module had similar issues; see bug 15275, bug 15471 for the issues, and r39935, r39936 (reverted in r39938), r39935, r40088, r40432 for attempts to solve them. The solution currently being used (as of r40432) introduces the ApiQueryBase::titlePartToKey() and keyPartToTitle() functions for normalizing title prefixes. They append an 'x' to their input, normalize that using ApiQueryBase::titleToKey() or keyToTitle() (which in turn use a Title object), then strip the 'x' again. Of course this is an ugly hack, and Title should really have this functionality on board. Maybe add a User::getCanonicalName()-style parameter somewhere?
Comment 5 Roan Kattouw 2009-01-07 13:58:35 UTC
Also, it could be useful to add that http://en.wikipedia.org/w/api.php?action=query&list=allpages&apprefix=. and apprefix=.. do work. So there's hope for this bug yet :)
Comment 6 db [inactive,noenotif] 2013-07-30 19:05:20 UTC
*** Bug 52010 has been marked as a duplicate of this bug. ***

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


Navigation
Links