Last modified: 2014-05-12 19:37:10 UTC
If you try to upload a file that contains HTML in the EXIF data using Special:Upload it gives you the following error: "This file contains HTML or script code that may be erroneously interpreted by a web browser." If you try to upload the same file using UploadWizard, it gives you the following error: "This file might be corrupt, or have the wrong extension." It would be nice if the UploadWizard error were more specific.
Hi, Ryan, two questions: 1. That message, I think, doesn't always show up where it used to. Could you confirm that this still happens? 2. Could you attach a file with HTML in the EXIF data for testing purposes? If you just fulfill number 2, I can test number 1. Thanks!
Recently, a patch to MediaWiki core [0] changed the behavior of API warnings. We now get those at the first step, even if we don't handle them necessarily. Could you try to reproduce this bug, and let us know if it still occurs? If so, the solution would likely be very different from before this patch. [0] https://gerrit.wikimedia.org/r/#/c/9261/ Thanks!
This is not yet fixed. This is a bug in the errors handlers. An API error is a code, an info and an optional 'details' array of message keys. We use the code to get a UW specific error description. Normally this description is in 'info', but we don't seem to use that one. The details are not passed at all. In this specific case we have: code: 'verification-error', info: "This file did not pass file verification", details: [ "uploadscripted"] The info corresponds to the msg of 'verification-error' The uploadscripted corresponds to a msg key for ""This file contains HTML or script code that may be erroneously interpreted by a web browser." Instead we display api-error-verification-error. Interesting observation, these api-error-* messages seem to be solely for UW, but are in the mediawiki-core translations.
For the entire error handler, we ought to implement something the likes of processVerificationError() of SpecialUpload.php we should expand showError() to showError(code, info, details) and pass details if the api error result has them. We can then also move the filetype-banned-type handling into showError.
Here is an example of a flickr file with some html in EXIF. Uploading https://www.flickr.com/photos/arthurhsu/8004910780/in/set-72157631578196004/ file using flickr version of UploadWizard results in "This file might be corrupt, or have the wrong extension." error. Upload of the same file manually (via local download) through UploadWizard gives "Internal error: Server failed to store temporary file." error. The old fashion Special:Upload gives the most clear "This file contains HTML or script code that may be erroneously interpreted by a web browser." error. Now I was able to figure out what is the issue, stripped all EXIF from the file and reuploded as https://commons.wikimedia.org/wiki/File:Coopers_Rock,_WV_-_Tomb_Raider_Roof_-_2.jpg UploadWizard should be able to strip HTML from the EXIF data, but if not than at least give more meaningful error message. Another example: https://www.flickr.com/photos/arthurhsu/8004906216/in/set-72157631578196004/
