Page MenuHomePhabricator
Create Task
Maniphest T32797

UploadWizard thumbnails broken in several browsers (IE, Opera)
Closed, ResolvedPublic
Actions

Description

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.

Version: unspecified
Severity: major

Details

Reference
bz30797
TitleReferenceAuthorSource BranchDest Branch
Update references for search platformrepos/data-engineering/airflow-dags-scap-search!1ebernhardsonwork/ebernhardson/configure-for-search-platformmain
Customize query in GitLab

Event Timeline

• bzimport raised the priority of this task from to High.Nov 21 2014, 11:49 PM
• bzimport added a project: UploadWizard.
• bzimport set Reference to bz30797.
Eloquence created this task.Sep 7 2011, 9:02 AM
• brion added a comment.Sep 7 2011, 6:53 PM

Created attachment 9025
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 "-IETFDTD 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] =&gt; 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?

Attached:

Screenshot-IE9-Win7-fail.png (1×951 px, 120 KB)

Catrope added a comment.Sep 7 2011, 10:15 PM

Ooh, this looks like something related to protocol-relative URLs is failing.

Catrope added a comment.Sep 7 2011, 10:16 PM

Do you have the data of the request that triggered that response?

• brion added a comment.Sep 7 2011, 10:27 PM

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...

Catrope added a comment.Sep 7 2011, 10:34 PM

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.

• brion added a comment.Sep 7 2011, 10:38 PM

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. :)

Catrope added a comment.Sep 8 2011, 1:48 PM

Hopefully fixed with r96562, will deploy later.

• brion added a comment.Sep 8 2011, 5:44 PM

Bug 30810 may be an example of same problem, or could be different -- should be tested again after the fix is deployed.

• bzimport added a comment.Sep 13 2011, 2:31 AM

neilk wrote:

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.

• Gilles added a project: Multimedia.Dec 4 2014, 10:19 AM
• Gilles raised the priority of this task from High to Unbreak Now!.Dec 4 2014, 10:21 AM
• Gilles moved this task from Untriaged to Done on the Multimedia board.
• Gilles lowered the priority of this task from Unbreak Now! to High.Dec 4 2014, 11:21 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL