Last modified: 2011-04-14 15:12:44 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 16781 - API and UI limits are inconsistent
API and UI limits are inconsistent
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: noncoreapi
  Show dependency treegraph
 
Reported: 2008-12-24 13:19 UTC by Gurch
Modified: 2011-04-14 15:12 UTC (History)
4 users (show)

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


Attachments

Description Gurch 2008-12-24 13:19:16 UTC
Many things (for example user contributions, page history, user list) have a limit of 5000 items when accessed through the UI, by anyone, but only 500 when accessed through the API by a 'normal user' (by default, non-bot, non-sysop). This is inconsistent, and if anything is backwards since UI requests entail more work server-side. Moving (semi-)automated queries from UI to API, something that is presumably desired, can thus result in up to 10 times as many requests needing to be made, surely more than negating all benefit to both ends brought about by using the API in the first place.

If 5000 is too much, should the UI limit be reduced, if not, should the API limit be raised? If the worry is that the API lends itself more easily to rapid queries, perhaps some sort of rate limit should be introduced for expensive queries?
Comment 1 Roan Kattouw 2008-12-24 13:55:20 UTC
(In reply to comment #0)
> If 5000 is too much, should the UI limit be reduced, if not, should the API
> limit be raised? If the worry is that the API lends itself more easily to rapid
> queries, perhaps some sort of rate limit should be introduced for expensive
> queries?
> 

I can't really comment on what's too high and what isn't, someone with more knowledge in the performance field should do that. Something that should be noted is that the 500/5000 limit in the API applies to each query separately, and since there are 34 query types in core (extensions like FlaggedRevs and GlobalBlocking provide even more), even a non-sysop user could get up to 34*500=17,000 results in one request.
Comment 2 Gurch 2008-12-24 16:00:56 UTC
(In reply to comment #1)
> I can't really comment on what's too high and what isn't, someone with more
> knowledge in the performance field should do that. Something that should be
> noted is that the 500/5000 limit in the API applies to each query separately,
> and since there are 34 query types in core (extensions like FlaggedRevs and
> GlobalBlocking provide even more), even a non-sysop user could get up to
> 34*500=17,000 results in one request.

True, I hadn't thought of that. I suppose that's a valid argument for keeping the limit down.

In practise, of course, there aren't any situations where such a request would provide results of any usefulness :)

Comment 3 Roan Kattouw 2008-12-24 16:23:55 UTC
(In reply to comment #2)
> In practise, of course, there aren't any situations where such a request would
> provide results of any usefulness :)
> 
While combining all 34 queries is obviously over the top and only really useful for testing or DoS purposes, combinations of 2 or 3 queries are quite common, and even combinations of 10 queries can be useful (all prop= modules combined, for instance). 
Comment 4 Gurch 2008-12-25 20:02:04 UTC
(In reply to comment #3)
> While combining all 34 queries is obviously over the top and only really useful
> for testing or DoS purposes, combinations of 2 or 3 queries are quite common,
> and even combinations of 10 queries can be useful (all prop= modules combined,
> for instance).

Yes, I've used a few such queries myself. Perhaps a 'maximum number of queries in one request' limit if DoS is a potential problem?

Comment 5 Roan Kattouw 2008-12-25 20:29:26 UTC
(In reply to comment #4)
> Yes, I've used a few such queries myself. Perhaps a 'maximum number of queries
> in one request' limit if DoS is a potential problem?
> 

Maybe, although I'm kind of leery of breaking backwards compatibility. I'll do this only if DoS is a real concern voiced by a developer with authority on the subject.
Comment 6 Gurch 2008-12-25 20:35:04 UTC
> Maybe, although I'm kind of leery of breaking backwards compatibility. I'll do
> this only if DoS is a real concern voiced by a developer with authority on the
> subject.

OK, just thinking of possibilities :)

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


Navigation
Links