Last modified: 2013-12-12 20:49:38 UTC
Created attachment 13061 [details] Internal error bad token on file upload showing URL This behavior started only recently, see screen shot. It might be a result of https://gerrit.wikimedia.org/r/#/c/75122/
I doubt it was that commit. It would be useful to test if this happens on both normal upload with the api and with chunked upload. Suosin in certain configs can cause this issue. Has beta had its php config modified recently?
> > Suosin in certain configs can cause this issue. Has beta had its php config > modified recently? Does not appear to be the issue ------------------ So this is super odd. When testing (using chunked upload. Not using upload wizard), I did not recieve any bad token errors related to uploading. However, ULS did get a bad token error when asking for user options (despite giving back the exact same token it received in a previous API request). When I did do chunked upload (using async. Not using upload wizard), everything proceeded normally, until the end when I received: {"servedby":"deployment-apache32","error":{"code":"stashfailed","info":"Internal error: Server failed to store temporary file."}} Which suggests a server misconfiguration. I have no idea what the badtoken to the uls request is about.
Ok, further testing (using upload wizard) reveals: The tokens api module is returning incorrect results. Things that request tokens from it are failing (including upload wizard and ULS). Things using tokens directly from the page source, are not failing.
Appears to be a varnish caching issue. Messing with the url gives back different tokens. Here is the headers of the bad token response (note the X-cache and Age headers): Accept-Ranges:bytes Age:1007218 Cache-Control:private, s-maxage=0, max-age=0 Connection:keep-alive Content-Encoding:gzip Content-Length:77 Content-Type:application/json; charset=utf-8 Date:Fri, 09 Aug 2013 18:56:35 GMT Server:Apache Vary:Accept-Encoding Via:1.1 varnish, 1.1 varnish X-Cache:deployment-cache-text1 hit (109), deployment-cache-text1 frontend miss (0) X-Content-Type-Options:nosniff X-Frame-Options:SAMEORIGIN X-Powered-By:PHP/5.3.10-1ubuntu3.6+wmf1 X-Varnish:967412333 965949056, 1692256446 X-Vary-Options:Accept-Encoding;list-contains=gzip
(In reply to comment #4) > Appears to be a varnish caching issue. So the question is whether this is a problem in the Varnish setup, or a problem in the response generated by MediaWiki that just happened to work with Squid? And if the former, what needs to change?
(In reply to comment #5 by anomie) > So the question is whether this is a problem in the Varnish setup, or a > problem in the response generated by MediaWiki that just happened to work > with Squid? > And if the former, what needs to change? Any idea who could answer this question and should be CC'ed?
(In reply to comment #6) > (In reply to comment #5 by anomie) > > So the question is whether this is a problem in the Varnish setup, or a > > problem in the response generated by MediaWiki that just happened to work > > with Squid? > > And if the former, what needs to change? > > Any idea who could answer this question and should be CC'ed? Well we use varnish on production now, so I don't think its a mediawiki issue, or production would be broken.
Not replicated since
