Mediawiki-api-announce

mediawiki-api-announce@lists.wikimedia.org

143 discussions

BREAKING CHANGE: Too high/low limits now throw warnings instead of errors
by Roan Kattouw 28 Aug '09

28 Aug '09

As of r55652 [1], passing a too high or too low value to a limit parameter will no longer cause an error, but throw a warning instead and continue with the maximum (for too high values) or the minimum (for too low values) limit. This was done to be nicer towards clients that could potentially be broken by the recent change to srlimit [2]. The change is not live on Wikipedia yet, but I will try to get it pushed live ASAP. Roan Kattouw (Catrope) [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/55652 [2] http://lists.wikimedia.org/pipermail/mediawiki-api-announce/2009-August/000…

1 0

BREAKING CHANGE: Maximum limit for list=search reduced from 500/5000 to 50/500
by Roan Kattouw 27 Aug '09

27 Aug '09

As of r55615 [1], which has gone live on Wikipedia yesterday, the maximum limit for list=search is 50 results for regular users and 500 for sysops and bots. This is down from 500/5000 because search queries using the maximum limit were causing performance issues. If you specify srlimit=100 or any number higher than your new maximum limit, you'll get an error message. If you specify srlimit=max , everything will keep working, but you'll get fewer results. Roan Kattouw (Catrope)

1 0

Re: [Mediawiki-api-announce] [Mediawiki-api] BREAKING CHANGE: HTTP 503 status code for maxlag errors
by Roan Kattouw 16 Jul '09

16 Jul '09

2009/7/16 Brad Jorsch <b-jorsch(a)northwestern.edu>: > On Wed, Jul 15, 2009 at 11:30:40PM +0200, Roan Kattouw wrote: >> >> As of r52190 [1], API maxlag errors (the kind of error you get when >> you set &maxlag=2 and the maximum slave lag is higher than two >> seconds) return a HTTP 503 status code rather than a 200, for >> consistency with index.php (which does the same thing). > > I agree with the others, this change should be reverted, as it is an > arbitrary breaking change that makes things more difficult for API > clients for consistency with something that is not really related. > Because of this and other complaints on the mediawiki-api list, I've reverted the change in r53353. It never went live on Wikipedia. Roan Kattouw (Catrope)

1 0

BREAKING CHANGE: HTTP 503 status code for maxlag errors
by Roan Kattouw 16 Jul '09

16 Jul '09

My apologies for sending out this e-mail so late. As of r52190 [1], API maxlag errors (the kind of error you get when you set &maxlag=2 and the maximum slave lag is higher than two seconds) return a HTTP 503 status code rather than a 200, for consistency with index.php (which does the same thing). The text of the response has not changed: <api> <error code="maxlag" info="Waiting for 10.0.6.38: 1 seconds lagged" /> </api> To trigger a maxlag error, you can set &maxlag=-1 [2]. Be aware that some client libraries may treat the 503 return code differently, which is why this could be a breaking change. Roan Kattouw (Catrope) [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/52190 [2] http://en.wikipedia.org/w/api.php?maxlag=-1&action=query

1 0

Fwd: [Mediawiki-api] Breaking change: cmnamespace parameter disabled
by Roan Kattouw 11 Jul '09

11 Jul '09

Forwarding to -announce list, sorry about the double-post to mediawiki-api ---------- Forwarded message ---------- From: Carl (CBM) <cbm.wikipedia(a)gmail.com> Date: 2009/7/10 Subject: [Mediawiki-api] Breaking change: cmnamespace parameter disabled To: mediawiki-api(a)lists.wikimedia.org The 'cmnamespace' parameter to the 'categorymembers' query has been disabled in miser mode, which has the effect of disabling it on WMF wikis. The parameter is simply ignored, causing category lists to include pages in all namespaces. The simplest workaround is to filter category lists locally. References: * http://www.mediawiki.org/wiki/Special:Code/MediaWiki/53052 * https://bugzilla.wikimedia.org/show_bug.cgi?id=19640 - Carl _______________________________________________ Mediawiki-api mailing list Mediawiki-api(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

1 0

BREAKING CHANGE: Queries may return fewer results than the limit and still set a query-continue
by Roan Kattouw 06 Feb '09

06 Feb '09

In r46845 [1], the issue raised in bug 11430 [2] a year and a half ago was finally addressed: when the API was asked to produce huge amounts of data (for instance the content of 500 revisions at 280 KB each), it would run out of memory trying to store and process it. To prevent this from happening, the amount of data the API can return is now limited. This means that the behavior of requests that used to run out of memory has changed: they will return fewer results than the limit, even though there are more results available (they'll still set query-continue right, though). For instance, the aforementioned request would return about 300 revisions and set a query-continue for the rest. Roan Kattouw (Catrope) [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/46845 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=11430

1 1

BREAKING CHANGE: rctitles removed from list=recentchanges
by roan.kattouw＠home.nl 05 Feb '09

05 Feb '09

In r46823 [1], the rctitles parameter was removed from list=recentchanges. Requests using this parameter were reported to time out on enwiki and take very long on other wikis. The removal of rctitles will go live on the Wikimedia servers shortly, and will appear in the MediaWiki 1.15 release (1.14 will still have rctitles). Roan Kattouw (Catrope) [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/46823

1 0

BREAKING CHANGE: Changed output format of prop=imageinfo&iiprop=metadata
by Roan Kattouw 04 Feb '09

04 Feb '09

As of r46766 [1], the output format used by prop=imageinfo to output metadata has changed. This change will appear in the MediaWiki 1.14 release (after I backport it, which has yet to be done) as well as go live on the Wikimedia servers on the next scap. The old format looked like this: <metadata version="1" length="110.93466666667"> <streams> <meta serial="1804289383" group="0" type="Vorbis" vendor="Xiph.Org libVorbis I 20030909" length="110.93466666667" size="1449257"> <header vorbis_version="0" audio_channels="2" audio_sample_rate="48000" bitrate_maximum="0" bitrate_nominal="112001" bitrate_minimum="0" blocksize_0="8" blocksize_1="11" framing_flag="0" /> <comments /dev/dsp="" title="Frédéric Chopin: Walzer Op. 64 No. 1 Des-Dur (Valse minute)" artist="Peter Gerwinski" comment="Licensed under GNU GPL" /> </meta> </streams> </metadata> Note that the <comments /dev/dsp="" ... /> part is invalid XML. This could happen because parts of the metadata is used in the attributes, which caused lots of bugs. The new format looks like this: <metadata> <metadata name="version" value="1" /> <metadata name="length" value="110.93466666667" /> <metadata name="streams"> <value> <metadata name="1804289383"> <value> <metadata name="serial" value="1804289383" /> <metadata name="group" value="0" /> ... </value> </metadata> </value> </metadata> </metadata> Note the use of name/value pairs, and note how nesting is done. Roan Kattouw (Catrope) [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/46766

1 1

BREAKING CHANGE: Providing prop=revisions&rvprop=content with too many titles or revisions causes warning instead of error
by Roan Kattouw 24 Oct '08

24 Oct '08

As of r42471 [1], prop=revisions&rvprop=content will no longer throw an error when too many titles or revisions are specified, but will throw a warning and ignore the superfluous titles/revisions. The warning message is identical to the one issued when too many values are specified for the titles or revids parameter. This change was made to fix bug 16074 [2], which occurred when a generator with gXXlimit=max (or any sufficiently high limit, really) was used to feed prop=revisions&rvprop=content, which would then throw an error because it was fed too many titles or revisions. However, the generator is not aware that prop=revisions threw away most of its results, and will set a query-continue as if this didn't happen. If this query-continue value is used by the client, a (potentially large) number of results will be skipped. When continuing such a request (i.e. one with a generator feeding prop=revisions&rvprop=content with a high or maximum limit), you have to set gXXlimit to a sufficiently low value first, so prop=revisions doesn't receive too many results and doesn't throw stuff away. The right number can be found in the text of the warning message, which is always something like "Too many values supplied for parameter 'titles': the limit is 50" (note that both 'titles' and the number 50 may vary). Finally, it should be noted that this behavior can only occur with prop=revisions&rvprop=content and only when a generator is used to feed it. All other modules and all uses of prop=revisions not involving both rvprop=content and a generator are not affected. Roan Kattouw (Catrope) [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/42471 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=16074

1 0

BREAKING CHANGE: action=protect to allow multiple expiries; output format, error messages changed
by Roan Kattouw 04 Oct '08

04 Oct '08

As of r41652 [1], action=protect allows the user to specify different expiry timestamps for different protections, something the UI has supported for a while. To support this, the expiry parameter has changed to accept multiple values, and even duplicate values. The first expiry timestamp will apply to the first protection, the second to the second, etc. The number of values in the expiry parameter must be equal to the number of values in the protections parameter, or an error will occur (for details on the new error message, see [2]). To preserve backwards compatibility, setting a single value in the expiry parameter is always allowed: in that case, all specified protections will have the same expiry timestamp. Example requests: api.php?action=protect&token=123ABC&title=Foo&protections=edit=sysop|move=sysop&expiry=infinite Will add the protections edit=sysop and move=sysop, both of which will never expire api.php?action=protect&token=123ABC&title=Foo&protections=edit=autoconfirmed|move=sysop&expiry=20081104000000|infinite Will add the protections edit=autoconfirmed and move=sysop; the first will expire on November 4, 2008, the second will never expire api.php?action=protect&token=123ABC&title=Foo&protections=edit=autoconfirmed|move=sysop|read=user&expiry=20081104000000|infinite Will cause an error, because 2 expiries were given for 3 protections api.php?action=protect&token=123ABC&title=Foo&protections=edit=autoconfirmed|move=sysop&expiry=20081104000000|infinite|infinite Will cause an error, because 3 expiries were given for 2 protections The output format has also been changed, so multiple expiry times can be listed. Old format: <protect title="Foo" reason="" expiry="infinite"> <protections edit="sysop" move="sysop" /> </protect> New format: <protect title="Foo" reason=""> <protections> <protection edit="sysop" expiry="infinite" /> <protection move="sysop" expiry="infinite" /> </protections> </protect> Additionally, the invalidexpiry and pastexpiry error messages have been changed to mention the expiry timestamp they're referring to. In the new messages, EXPIRY is replaced by the faulty expiry timestamp. Old messages: * code: invalidexpiry ** info: Invalid expiry time * code: pastexpiry ** info: Expiry time is in the past New messages: * code: invalidexpiry ** info: Invalid expiry time ``EXPIRY'' * code: pastexpiry ** info: Expiry time ``EXPIRY'' is in the past For the newly added error message toofewexpiries or more information about action=protect, see the documentation at www.mediawiki.org [2]. [1] http://svn.wikimedia.org/viewvc/mediawiki/?view=rev&rev=41652 [2] http://www.mediawiki.org/wiki/API:Edit_-_Protect

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Mediawiki-api-announce