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;

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;

----- 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 8:31 PM, Jay Ashworth wrote: About 40% of the users of Wikipedia are using Internet Explorer. For all of those users, unless I am misunderstanding the problem, some of our API functions are currently disabled. We have a few deployed extensions that make use of these API functions specifically. The only two I know about personally are WikiLove and UploadWizard. It sounds like UploadWizard is already working around this problem according to Neil, so the impact may be limited to WikiLove and individual/bot API use. Within WikiLove, the problem seems to be limited to the "make your own" feature. There may be other extensions that are affected as well, but I haven't checked. Ryan Kaldari