Last modified: 2009-09-23 14:14:26 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 T22780, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20780 - Upload of MIDI file erroneously rejected
Upload of MIDI file erroneously rejected
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Bryan Tong Minh
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-23 11:23 UTC by Michael Bednarek
Modified: 2009-09-23 14:14 UTC (History)
3 users (show)

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


Attachments

Description Michael Bednarek 2009-09-23 11:23:24 UTC
Uploading the MIDI file at http://mbednarek.com/temp/maidensprayer.mid results in the error message: "This file contains HTML or script code that may be erroneously interpreted by a web browser."

According to user Splarka at http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=315675310#Upload_MIDI this happend because this particular file happened to have the string "<A" in its first 1024 characters. That string is part of a valid MIDI instruction.

Binary files, like MIDI files, should not be subject to screening for text strings; fragments like "<A" in this case can obviously occur outside the context of "HTML or script code."

User Splarka mentioned that "UploadBase.php" might be at the core of the problem.
Comment 1 Splarka 2009-09-23 13:22:23 UTC
Also got this with http://commons.wikimedia.org/wiki/File:Loading.gif
Comment 2 Bryan Tong Minh 2009-09-23 13:48:30 UTC
Something went wrong when I tried to merge r43627 in the new-upload branch with r45378, it should detect '<a href='

Comment 3 Derk-Jan Hartman 2009-09-23 13:51:40 UTC
Shouldn't that be '<a'*'href=', because <a title="woot i haxored you" href= would still do the trick of course.
Comment 4 Splarka 2009-09-23 14:00:05 UTC
> Shouldn't that be '<a'*'href=', because <a title="woot i haxored you" href=
> would still do the trick of course.

IE specifically checks for '<A HREF' and since the only reason to have this detection is to pre-guess IE, it just needs to find '<A HREF'. I think.
Comment 5 Roan Kattouw 2009-09-23 14:00:47 UTC
(In reply to comment #3)
> Shouldn't that be '<a'*'href=', because <a title="woot i haxored you" href=
> would still do the trick of course.
> 

Like the comments in IEContentAnalyzer.php say, the objective is to emulate IE's broken MIME detection code, not to be correct. You've just pointed out an obvious flaw in IE's algorithm, which IEContentAnalyzer duplicates because its purpose is to predict how IE will react.
Comment 6 Bryan Tong Minh 2009-09-23 14:08:38 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > Shouldn't that be '<a'*'href=', because <a title="woot i haxored you" href=
> > would still do the trick of course.
> > 
> 
> Like the comments in IEContentAnalyzer.php say, the objective is to emulate
> IE's broken MIME detection code, not to be correct. You've just pointed out an
> obvious flaw in IE's algorithm, which IEContentAnalyzer duplicates because its
> purpose is to predict how IE will react.
> 

Note that this is UploadBase::detectScript, which is separate of IEContentAnalyzer. I don't exactly understand if and how those two functions are related and whether UploadBase::detectScript duplicated functions of IEContentAnalyzer.
Comment 7 Bryan Tong Minh 2009-09-23 14:14:26 UTC
r56817.

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


Navigation
Links