From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Description of problem: In FC4 mime_content_type returns bad MIME (text/plain) for png files. I tested this with FC3 and it works fine. Version-Release number of selected component (if applicable): php-5.0.5-2.1 How reproducible: Always Steps to Reproduce: 1. Install FC4 2. Update 3. php -r 'print("[" . mime_content_type("blank-ico64.png") . "]\n");' Actual Results: [text/plain] Expected Results: [image/png] Additional info:
I confirm this bug.
Bad news: the bug is still not fixed in FC5 and even FC6. I have just checked both. Even more bad news: this PHP function (i.e. mime_content_type) is used in Mediawiki to check the image file while it is being uploaded to wiki -- and this bug makes it unable to upload PNG files to mediawiki installed on FC4/5/6 system -- it's a pity and it's a shame. Good news: the fix is one-liner to spec file: --- php.spec.mime 2007-01-13 02:24:30.000000000 +0300 +++ php.spec 2007-01-13 02:23:37.000000000 +0300 @@ -421,7 +421,7 @@ --enable-calendar \ --enable-dbx \ --enable-dio \ - --with-mime-magic=%{_sysconfdir}/httpd/conf/magic \ + --with-mime-magic=%{_datadir}/file/magic \ --without-sqlite \ --with-libxml-dir=%{_prefix} \ --with-xml \ Details: without this patch, mime_content_type uses Apache's magic file, which is _much_ times shorter than that of file(1) utility and does not contain any magic for PNG files. By reverting to use file's magic file, this is fixed. I though it is also needed to add requirements for "file", but it's already there in spec -- so I suppose file's magic was used some time before... Hope I made it clear enough to finally fix this nasty bug.
Bug is valid for FC6 as well, so please change "version" accordingly -- since I don't have permission to.
Created attachment 145497 [details] proposed fix
Created attachment 145502 [details] proposed fix (correct) I'm sorry, previous attachment and patch in comment #2 is wrong. Correct patch is attached, correct fix is the following: - --with-mime-magic=%{_sysconfdir}/httpd/conf/magic \ + --with-mime-magic=%{_datadir}/file/magic.mime \ Please note that magic.mime file (from file(1) utility) is only about two times larger than magic file (from Apache), so it should not create any additional overhead or smth. I have also checked php behavior on RHEL4 (actually CentOS4) -- php reads /usr/share/file/magic.mime there (i.e. same as after my patch).
For images getimagesize() can be used as a workaround, but a real fix would be better (c'mon, png is not that rare file type). Should this bug be reported upstream?
In latest FC6 updates (now, 2007-03-20) the example returns empty string, not text/plain. Also it segfault-ed on one jpeg and recognized only text/plain, text/html - no video, sound, document was recognized (they seem to exist in apache's mime file) except some that got text/plain. Swapping /usr/share/file/magic.mime to /etc/httpd/conf/mime did nothing more, so the problem is not the mime file that ships with apache. Someone willing to look if PHP has this bug reported?
Quick and easy check: for i in *; do [ -f "$i" ] && echo -n "$i: " && php -r 'print("[" . mime_content_type("'"$i"'") . "]\n");'; done
The extension is deprecated upstream in favour of PECL::Fileinfo. Did the change to use /usr/share/file/magic.mime in the latest updates make things worse or better?
No for me, I have file-4.19-2.fc6 and even after manual change of the magic file [ cd /etc/httpd/conf; mv magic magic.dist ln -s /usr/share/file/magic.mime magic ] my example from comment #8 does not recognize a single graphical file I have. php-pecl-Fileinfo is in extras, but I had to download the source to see how it works, thanks for the info. This bug was not present in FC1 (at least), but don't downgrade php/apache, please ;-)
phpinfo() show '--with-mime-magic=/usr/share/file/magic' on fedora6. so, this path wrong and NOT /etc/httpd/conf/magic and i can't copy /usr/share/file/magic.mime to /usr/share/file/magic because i think some other software will work wrong.
It's too late for FC6 and this function is missing from php-5.2.5-2.fc8. Can't/Won't fix?
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.