Last modified: 2012-04-19 21:22:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28367, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26367 - Uploading fails with "internal error: key 'ljg40qoexthbj3vu8f9875e5uspj37n.' is not in a proper format"
Uploading fails with "internal error: key 'ljg40qoexthbj3vu8f9875e5uspj37n.' ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.18.x
All All
: Normal major (vote)
: 1.18.0 release
Assigned To: Neil Kandalgaonkar
http://spiele.j-crew.de/wiki/Spezial:...
:
: 26368 (view as bug list)
Depends on:
Blocks: 26611
  Show dependency treegraph
 
Reported: 2010-12-19 15:58 UTC by Thomas Bleher
Modified: 2012-04-19 21:22 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Thomas Bleher 2010-12-19 15:58:17 UTC
Whenever I try to upload a file to my wiki (http://spiele.j-crew.de/wiki/Spezial:Hochladen), the upload fails with the following backtrace:

key 'ljg40qoexthbj3vu8f9875e5uspj37n.' is not in a proper format
Backtrace:
#0 /srv/www/mediawiki/code/includes/upload/UploadBase.php(642): UploadStash->stashFile('/tmp/phpoM0taX', Array, NULL)
#1 /srv/www/mediawiki/code/includes/upload/UploadBase.php(654): UploadBase->stashSessionFile(NULL)
#2 /srv/www/mediawiki/code/includes/specials/SpecialUpload.php(367): UploadBase->stashSession()
#3 /srv/www/mediawiki/code/includes/specials/SpecialUpload.php(461): SpecialUpload->showUploadWarning(Array)
#4 /srv/www/mediawiki/code/includes/specials/SpecialUpload.php(192): SpecialUpload->processUpload()
#5 /srv/www/mediawiki/code/includes/SpecialPage.php(580): SpecialUpload->execute(NULL)
#6 /srv/www/mediawiki/code/includes/Wiki.php(245): SpecialPage::executePath(Object(Title))
#7 /srv/www/mediawiki/code/includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#8 /srv/www/mediawiki/code/w/index.php(103): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#9 {main}

I tried it with the svg file from http://commons.wikimedia.org/wiki/File:Gtk-dialog-info.svg, feel free to make your own tests on the wiki, if it helps determining the cause.
Comment 1 Thomas Bleher 2010-12-19 16:38:27 UTC
I tracked the problem down a bit, and it seems to be a problem in includes/MimeMagic.php.

MimeMagic has a list of predefined mime types, with assorted file extensions.
The code that parses the types treats everything up to the first space as the mime type, everything behind that as a file extension. As you can see from the diff below, the svg line does not follow this convention, leading to an extension of "image/svg".
This blows up in UploadStash.

With the change below, I can upload svg files again. But I'm not sure what the correct fix is here, as this particular line is in the code since r21411, from April 2007.

--- a/includes/MimeMagic.php
+++ b/includes/MimeMagic.php
@@ -41,7 +41,7 @@ image/x-bmp bmp
 image/gif gif
 image/jpeg jpeg jpg jpe
 image/png png
-image/svg+xml image/svg svg
+image/svg+xml svg
 image/tiff tiff tif
 image/vnd.djvu image/x.djvu image/x-djvu djvu
 image/x-portable-pixmap ppm
Comment 2 Raimond Spekking 2010-12-19 18:13:24 UTC
*** Bug 26368 has been marked as a duplicate of this bug. ***
Comment 3 Neil Kandalgaonkar 2010-12-21 01:02:22 UTC
Great work Thomas -- however it seems that other lines in the file follow the same convention. Perhaps the intention is to create equivalency between a list of mimetypes and a list of extensions, and one is supposed to just intuit that a mimetype has a slash and an extension doesn't.

This might be a bug in MimeMagic -- if you want to look into it further, that would be awesome, but I'm going to look into it anyway if you don't have the time.



 (In reply to comment #1)
> I tracked the problem down a bit, and it seems to be a problem in
> includes/MimeMagic.php.
> 
> MimeMagic has a list of predefined mime types, with assorted file extensions.
> The code that parses the types treats everything up to the first space as the
> mime type, everything behind that as a file extension. As you can see from the
> diff below, the svg line does not follow this convention, leading to an
> extension of "image/svg".
> This blows up in UploadStash.
> 
> With the change below, I can upload svg files again. But I'm not sure what the
> correct fix is here, as this particular line is in the code since r21411, from
> April 2007.
> 
> --- a/includes/MimeMagic.php
> +++ b/includes/MimeMagic.php
> @@ -41,7 +41,7 @@ image/x-bmp bmp
>  image/gif gif
>  image/jpeg jpeg jpg jpe
>  image/png png
> -image/svg+xml image/svg svg
> +image/svg+xml svg
>  image/tiff tiff tif
>  image/vnd.djvu image/x.djvu image/x-djvu djvu
>  image/x-portable-pixmap ppm
Comment 4 Bryan Tong Minh 2011-01-07 19:09:13 UTC
For some reason your MediaWiki is not able to find mime.types, which in itself is odd, but the fallback is broken. I'm looking into the proper format for it.
Comment 5 Bryan Tong Minh 2011-01-07 19:44:00 UTC
This should be fixed by r79835. However I think the real reason is UploadStash requiring the stash key to have an extension. Is there a specific reason for this? It seems to just work even if the extension does not match the mime type at all.
Comment 6 Neil Kandalgaonkar 2011-01-08 05:25:09 UTC
There is no reason for the stash key to have an extension, other than paranoia that some browsers might get confused when displaying previews or the full thing. In fact, it used to not have an extension (or rather, it claimed to have one and then discarded it). For simplicity I just made it have an extension.
Comment 7 Bryan Tong Minh 2011-01-08 11:55:13 UTC
I guess we should make the extension optional, as it also breaks uploading files without extension.
Comment 8 Neil Kandalgaonkar 2011-01-08 14:02:15 UTC
Well, to my knowledge, it was *always* an error to upload files without an extension, at least for Wikimedia wikis -- an error is shown client-side. That's why I felt confident making that a requirement. I was trying to change as few things as possible.

I agree that it is a bit silly, since we are doing a mime type check anyway. If I were designing the system from scratch, I would analyze the file server side and canonicalize to one extension (rather than have, for instance, jpeg and jpg co-existing). But the rule was just -- if there's no jpg, png, gift, etc, we don't even let you begin to upload this.
Comment 9 Roan Kattouw 2011-01-08 15:24:06 UTC
(In reply to comment #8)
> Well, to my knowledge, it was *always* an error to upload files without an
> extension, at least for Wikimedia wikis -- an error is shown client-side.
> That's why I felt confident making that a requirement. I was trying to change
> as few things as possible.
> 
If the *target* (on-wiki) name is extensionless, maybe. But with stashed uploading, the user hasn't even entered the target name yet, so I'm guessing this is based on the local filename instead, which is evil: we should make *zero* assumptions from the local filename, other than maybe prefilling the target name.
Comment 10 Neil Kandalgaonkar 2011-01-08 22:15:50 UTC
(In reply to comment #9)

> We should make
> *zero* assumptions from the local filename, other than maybe prefilling the
> target name.

Agreed. On the other hand, if I spent time correcting everything about MediaWiki that didn't make sense to me I'd never get anything done. ;) Still, maybe we can fix THIS, since it seems to be actually harmful.

I'm sorry I haven't gotten around to addressing this yet.
Comment 11 Thomas Bleher 2011-01-09 11:23:27 UTC
(In reply to comment #5)
> This should be fixed by r79835.

On my wiki, r79835 indeed fixes the issue I saw, and I can upload SVG files again.
I also looked at the code, and think that your description is correct.
Thanks for your work (the same goes to NealK)!
Comment 12 Roan Kattouw 2011-01-14 19:36:19 UTC
(In reply to comment #11)
> (In reply to comment #5)
> > This should be fixed by r79835.
> 
> On my wiki, r79835 indeed fixes the issue I saw
Marking as FIXED then.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links