Last modified: 2008-03-03 10:09:23 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 13157 - CIDR ranges api.php
CIDR ranges api.php
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Roan Kattouw
http://en.wikipedia.org/w/index.php?t...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-26 04:08 UTC by Splarka
Modified: 2008-03-03 10:09 UTC (History)
1 user (show)

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


Attachments

Description Splarka 2008-02-26 04:08:50 UTC
After r30578 it is now possible to list multiple parameters to &list=usercontribs&ucuser= ... this also creates the possibility for very efficient pseudo-CIDR lookups, eg:

 &list=usercontribs&ucuser=1.2.3.0|1.2.3.1|1.2.3.2|1.2.3.3|1.2.3.4| ... |1.2.3.255

A typically tested /24 takes only .4 seconds on en.wp, and goes back to at least 2002. However the URI limit at Wikimedia seems to be about 4000 characters, slightly liming the usefulness of this (and using format=json in a <script> precludes using POST).

Could this behavior, then, be supported natively? Either via CIDR formatting? say up to /24 for normal users, and maybe as far as /20 or even /16 for bots (which could take over a minute):

 &list=usercontribs&ucuser=1.2.3.0/24

Or perhaps some sort of prefix parameters: &ucuserprefix=1.2.3. (though this may not be optimal)

Whichever is most efficient to the current design of parallel user lookup, while allowing a shorter URL.
Comment 1 Roan Kattouw 2008-02-26 10:10:51 UTC
I'll look into this.
Comment 2 Roan Kattouw 2008-02-26 16:58:22 UTC
I implemented your latter suggestion (ucuserprefix) in r31312. Keep in mind that ucuserprefix doesn't take multiple values (for efficiency reasons), also works for regular user names and overrides ucuser if present.
Comment 4 Roan Kattouw 2008-03-03 10:09:23 UTC
(In reply to comment #3)
> Seems to work great for CIDR! One problem I've run in to though using
> ucuserprefix for regular user names... how do you encode spaces?
>
That was a bug, fixed in r31489. Tim%20Star works now.

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


Navigation
Links