On Fri, Jul 1, 2011 at 2:23 PM, Dirt Diver <info(a)dirtdiver.org> wrote: Rate limits affect edits, rollbacks and moves only. They are applied both in the UI and in the API (although you probably have to try pretty hard to hit them in the UI). On Wikimedia wikis, the rate limit for editing is 8 edits per minute for anonymous (logged-out) and new users. So waiting 3 seconds between edits will result in almost 20 edits per minute, that's way too much. If you're operating a bot, you should get an account for it and ask for a bot flag. That way you'll be exempt from rate limits and the bot's edits will be hidden from Special:RecentChanges if you pass &bot=1 in the action=edit call. Roan Kattouw (Catrope)

On Fri, Jul 1, 2011 at 5:59 PM, Platonides &lt;Platonides(a)gmail.com&gt; wrote: It's a moot point anyway, Abigor's bot was globally blocked: <http://meta.wikimedia.org/w/index.php?title=Steward_requests%2FGlobal&action=historysubmit&diff=2693470&oldid=2693415> -- Casey Brown Cbrown1023

----- Original Message ----- FWIW, I get an XML file here, which Firefox is nice enough to show the source of, because there's no XSL associated with it. Road Runner Tampa Bay, IPv4; FF 4.0.1; SuSE 11.3. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

On Sun, Jul 3, 2011 at 3:21 AM, Ryan Kaldari &lt;rkaldari(a)wikimedia.org&gt; wrote: Is he using IE6? I think we still haven't deployed the proper fixes for the IE6 extension issue yet, although they did go into the 1.17 release. Roan

Ryan Kaldari &lt;rkaldari(a)wikimedia.org&gt; wrote: It seems to be related to the User-Agent header: | [tim@passepartout ~]$ wget --user-agent="Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C)" 'http://en.wikipedia.org/w/api.php?action=query&format=xml&titles=File%3ATrophy.png&prop=imageinfo' | --2011-07-03 19:28:45-- http://en.wikipedia.org/w/api.php?action=query&format=xml&titles=Fi… | Resolving en.wikipedia.org... 91.198.174.232 | Connecting to en.wikipedia.org|91.198.174.232|:80... connected. | HTTP request sent, awaiting response... 403 Forbidden | 2011-07-03 19:28:45 ERROR 403: Forbidden. | [tim@passepartout ~]$ wget --user-agent="abc" 'http://en.wikipedia.org/w/api.php?action=query&format=xml&titles=File%3ATrophy.png&prop=imageinfo'--2011-07-03 19:28:47-- http://en.wikipedia.org/w/api.php?action=query&format=xml&titles=Fi… | Resolving en.wikipedia.org... 91.198.174.232 | Connecting to en.wikipedia.org|91.198.174.232|:80... connected. | HTTP request sent, awaiting response... 200 OK | Length: 295 [text/xml] | Saving to: `api.php?action=query&format=xml&titles=File:Trophy.png&prop=imageinfo' | 100%[===================================================================================================================>] 295 --.-K/s in 0.001s | 2011-07-03 19:28:48 (386 KB/s) - `api.php?action=query&format=xml&titles=File:Trophy.png&prop=imageinfo' saved [295/295] | [tim@passepartout ~]$ Tim

That means that the Make Your Own feature in WikiLove and some of the features in UploadWizard are broken for almost half our users. Is there any way to deploy that fix sooner than Thursday? Alternately, could we do a live fix by changing "MSIE" to "MSIE 6" on the cluster? (I have no idea if that is totally insane or a reasonable suggestion.) Ryan Kaldari On 7/3/11 12:46 PM, Roan Kattouw wrote:

If I am up to date here, the fix that exists in trunk for the API-handling code is still not going to help us. It merely excludes highly improbable "extensions" like ".jpg&foo=bar&quux=blarg". But, what if your query arguments *legitimately* end with an extension like "http://en.wikipedia.org/w/api.php?action=doSomething&page=File:Something.jpg" ? You can't depend on query argument order. The only solution is to encode our queryargs differently. So, in the last deploy I deployed a workaround for this in UploadWizard. At the last stage before firing the AJAX query I convert any '.' in the query data to '%2E'. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90649 This won't trigger any bizarre bugs in IE6 and your code (if properly written) should never know anything happened. We could advise other consumers of our API to do the same. BTW, this is a fairly tricky fix as it relies on certain quirks of jQuery 1.3, which is what we have deployed. Also, it was easier for me to deploy this fix for UW because all its ajax calls go through an API object. In jQuery 1.4 you can fix this in a more standardized way, with ajax filters. Of course it would be better if we just fixed the XSS prevention somehow, but I don't see how that's possible given the constraints. On 7/3/11 1:09 PM, Ryan Kaldari wrote: -- Neil Kandalgaonkar ) &lt;neilk(a)wikimedia.org&gt;

----- Original Message ----- So that we have a good feeling for impact, given Roun's reply -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

On 7/3/11 2:55 PM, Roan Kattouw wrote: Er, sorry, my TARDIS was set to 2009 or something. I got the version numbers wrong in my post, but the basic premise stands. You can fix it with ajax prefilters in jQuery >1.5, and in 1.4 you must stringify the data attribute of the AJAX call and s/\./%2e/g; before sending it. -- Neil Kandalgaonkar ) &lt;neilk(a)wikimedia.org&gt;

Tim has fixed the issue on the live wikis. I imagine he just pushed up the fix that was already on trunk, so we probably still need to fix it for the case mentioned by Neil. Ryan Kaldari On 7/3/11 11:41 PM, Neil Kandalgaonkar wrote: