|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75380 finfo_file treats XML file as text/xml
Submitted: 2017-10-15 08:50 UTC Modified: 2017-11-05 04:23 UTC
Avg. Score:4.2 ± 0.7
Reproduced:9 of 11 (81.8%)
Same Version:8 (88.9%)
Same OS:5 (55.6%)
From: d dot naumenko dot a at gmail dot com Assigned:
Status: No Feedback Package: Filesystem function related
PHP Version: 7.2.0RC4 OS: 3v4l
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2017-10-15 08:50 UTC] d dot naumenko dot a at gmail dot com
Before PHP 7.2.0 alpha1, function `finfo_` function called on XML input returned mime-type `application/xml`. Since PHP7.2 alpha1 it returns `text/xml`.

When I put the same XML document as in test script bellow to the file and call linux program `file` on it, I see expected result:

$> file --mime-type test.xml
test.xml: application/xml

Test script:

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-10-26 16:29 UTC]
-Status: Open +Status: Feedback
 [2017-10-26 16:29 UTC]
Thanks for the report. Why is it supposed to be a bug? Seems the behavior is intentional in the upstream data. Also wrt RFC 7303 the types are same. The data version depends on the file utility version and a particular distro.

 [2017-10-26 16:38 UTC] spam2 at rhsoft dot net
because it's terrible when you have a difference between file in your terminal and PHP caused by the fork of libmagic and bundle it instead using system libraries

this leads to some images reported as applications/octed-stream over now 5 years while a report at the Linux distribution fixed it within days for the cli utility

using Zend memory manager and open-basedir don't justify the fork, the memory manager don't matter, open_basedir should be checked way earlier before calling library code at all and for stream wrappers temp files in the shim layer would be a solution
 [2017-10-26 16:55 UTC]
@spam2, thanks, but that's not the factual feedback on the actual MIME type diff reported.

 [2017-11-05 04:23 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2018-12-17 09:54 UTC] mwaghmare7 at gmail dot com
Getting different REAL MIME type from function finfo_file.

The issue may be the different Operating Systems or due to Different PHP versions.

But, While debugging the issue, When I try to upload the XML on localhost I got the text/xml as a real MIME type and on live site it's application/xml.

Below is the debugging steps:

File: /wp-includes/functions.php line 2346

// Validate files that didn't get validated during previous checks.
if ( $type && ! $real_mime && extension_loaded( 'fileinfo' ) ) {
	$finfo = finfo_open( FILEINFO_MIME_TYPE );
	$real_mime = finfo_file( $finfo, $file );
	finfo_close( $finfo );

	echo '<pre>';
	var_dump( FILEINFO_MIME_TYPE ) . '<br/>';
	var_dump( $finfo ) . '<br/>';
	var_dump( $file ) . '<br/>';
	var_dump( $real_mime ) . '<br/>';
The output of the above code is below on LOCALHOST:

PHP: Version 7.2.4
System: Windows NT M 6.3 build 9600 (Windows 8.1 Professional Edition) i586
resource(767) of type (Unknown)
string(46) "C:\Users\Yum\AppData\Local\Temp/wxr-LccAYF.tmp"
string(8) "text/xml"
But, It is different on the LIVE site.

PHP: Version
System: Linux ip-172-31-25-204 4.4.0-134-generic #160-Ubuntu SMP Wed Aug 15 14:58:00 UTC 2018 x86_64
resource(747) of type (Unknown)
string(19) "/tmp/wxr-YNkiH5.tmp"
string(15) "application/xml"
 [2019-07-22 10:54 UTC] nemanja at testseek dot com
This is really a regression caused by upstream. 

Now after upgrade to 7.3 I need to refactor constants...
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Feb 23 07:01:28 2024 UTC