Last modified: 2011-09-13 02:31:29 UTC
Based on checks in IE8, IE9 (Windows 7) and Opera 9.63 (Ubuntu Natty) it looks like thumbnails not generated through the FileAPI (bug 29248) may be currently broken in production on Wikimedia Commons. In a nutshell, thumbnails for images in these tested and probably other browsers either appear as white boxes, or as the broken thumbnail image, on any step in the process. Clicking the image does result in an enlarged preview. For reasons that are mysterious even to me, I've used http://www.fishfarmingbusiness.com/wp-content/uploads/2011/03/FishDancing.jpg for testing purposes.
Created attachment 9025 [details] Screenshot IE 9 / Win7 w/ failure response details This may be an intermittent problem -- I made one attempt and it was just fine, with a visible thumbnail shown after the file upload. But a second attempt (this time with capturing on in the network debug stuff in F12 developer tools) showed up the error; a 500 Internal Server Error was returned from the Special:UploadStash request for the thumbnail, with this response body: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head><title>Internal Server Error</title></head> <body> <h1>Internal Server Error</h1> <p>Fetching thumbnail failed: Array<br /> (<br /> [0] => http-invalid-url<br /> )<br /> <br /> url = //upload.wikimedia.org/wikipedia/commons/thumb/temp/f/fe/20110907184933!phpGplttg.jpg/88px-20110907184933!phpGplttg.jpg<br /> </p></body></html> It's possible that there's some deployment inconsistency causing some requests to fail and others to be ok with the config?
Ooh, this looks like something related to protocol-relative URLs is failing.
Do you have the data of the request that triggered that response?
Unfortunately no, and for some reason I can no longer successfully upload files on Commons in my IE 9 VM. It seems to get stuck on the upload POST and just never finishes or errors out, so it never gets as far as the thumb request anymore. Sigh...
SpecialUploadStash::outputRemoteScaledThumb() has this: $scalerThumbUrl = $wgUploadStashScalerBaseUrl . '/' . $file->getUrlRel() . '/' . rawurlencode( $scalerThumbName ); Where $wgUploadStashScalerBaseUrl may be protocol-relative. Then this URL is fed straight into MWHttpRequest::factory(), which can't deal with protocol-relative URLs at all (it feeds them straight into parse_url(), which is severely broken for protocol-relative URLs. Why doesn't this use wfParseUrl(), anyway?). I'll fix both issues tomorrow, I need sleep now.
Got one to work again, though per above we already figured the problem is on the inside and should be fixable. Req: Key Value Request GET /wiki/Special:UploadStash/thumb/zz89zibobfo.5h72oi.123.jpg/88px-zz89zibobfo.5h72oi.123.jpg HTTP/1.1 Accept image/png, image/svg+xml, image/*;q=0.8, */*;q=0.5 Referer http://commons.wikimedia.org/wiki/Special:UploadWizard Accept-Language en-US User-Agent Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) Accept-Encoding gzip, deflate Host commons.wikimedia.org Connection Keep-Alive (cookies removed) The mapping to the low-level internal URL is done internally from the keyname on the URL params, then it's crapping out from pushing the protocol-relative URL into an HTTP request. :)
Hopefully fixed with r96562, will deploy later.
Bug 30810 may be an example of same problem, or could be different -- should be tested again after the fix is deployed.
The feature of obtaining previews from the scaler was broken due to a config change. This didn't affect modern Chrome or Firefox since we have a number of techniques that we use with those browsers to obtain thumbnails locally. The offending config change was that someone changed the URL of the Upload Stash scaler to a protocol relative URL. Since it is the server itself which obtains these images and then streams them to the client, the protocol relative URL made no sense, and caused 500 errors. Fixed in wmf-config revision r2266, with a note on why this URL shouldn't be protocol-relative. Deployed and seems to have fixed the issue. Also, raindrift added a change in r96934 to add the protocol back if someone accidentally makes this config change again.
