php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79045 Incorrect svg mimetypes detected
Submitted: 2019-12-30 01:30 UTC Modified: 2019-12-30 12:20 UTC
Votes:2
Avg. Score:3.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: sloth at 0k dot vc Assigned:
Status: Open Package: Filesystem function related
PHP Version: 7.2.26 OS: Centos 7.5
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: sloth at 0k dot vc
New email:
PHP Version: OS:

 

 [2019-12-30 01:30 UTC] sloth at 0k dot vc
Description:
------------
PHP when given an svg perhaps without the xml header, will return a mime type of image/svg instead of image/svg+xml, however IANA does not list image/svg as an existant mimetype, nor do browsers display it. (https://www.iana.org/assignments/media-types/media-types.xhtml)

By SVG standards, mimetype returned should always be image/svg+xml, php should also behave consistently for a single type of file. If this is being used to differentiate properly headered SVGs from those that are not as strict, this should be done as part of a file validity check not a mime type check.

Previously reported bug (https://bugs.php.net/bug.php?id=76543) was indicated as "Not a bug" due to it being deemed as upstream fault with libmagic. However, libmagic returns svgs missing the xml header as text/plain. This indicates the fault is in the adaptations PHP took to remove that error.

└(~) $ file -i Test.svg
Test.svg: image/svg+xml; charset=utf-8
└(~) $ file -i badge.svg
badge.svg: text/plain; charset=us-ascii

As only php is returning image/svg and this is not a registered mimetype, this can be considered a bug with php.

Test images:
Working svg+xml: https://upload.wikimedia.org/wikipedia/commons/b/bd/Test.svg
SVG returned as image/svg: https://img.shields.io/badge/License-WTFPL-brightgreen.svg

Test script:
---------------
<?php
echo mime_content_type('./badge.svg'), "\n";
echo mime_content_type('./Test.svg'), "\n";

$finfo = new finfo(FILEINFO_MIME);

$buffer = file_get_contents('./badge.svg');
echo $finfo->buffer($buffer) . "\n";
$buffer = file_get_contents('./Test.svg');
echo $finfo->buffer($buffer) . "\n";


Expected result:
----------------
image/svg+xml
image/svg+xml
image/svg+xml; charset=us-ascii
image/svg+xml; charset=utf-8


Actual result:
--------------
image/svg
image/svg+xml
image/svg; charset=us-ascii
image/svg+xml; charset=utf-8


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-12-30 01:41 UTC] sloth at 0k dot vc
-Summary: incorrect svg mimetypes +Summary: Incorrect svg mimetypes detected
 [2019-12-30 01:41 UTC] sloth at 0k dot vc
More descriptive title
 [2019-12-30 02:01 UTC] phpbugs-xap2kka at mpan dot pl
With PHP 7.4.1 returns the same, bug file 5.37 (on Arch) offers a different output:

Test.svg:  image/svg+xml; charset=utf-8
badge.svg: image/svg; charset=us-ascii

That doesn’t explain, however, why is PHP 7.2.26 returning a different value and why “image/svg” is returned instead of “image/svg+xml”. I do understand that badge.svg is not an XML file and one may be tempted to remove that “+xml”, but if it is not an XML, it is also not an SVG and “image/svg” is equally incorrect. Plus it is not the registered type for SVG.
 [2019-12-30 02:03 UTC] phpbugs-xap2kka at mpan dot pl
“With PHP 7.4.1 *it* returns the same, *but* file 5.37 (on Arch) offers a different output” of course. Too many bugs. :)
 [2019-12-30 12:20 UTC] cmb@php.net
The result depends on the version of the magic data; for vanilla
`file`:

as of file 5.38: image/svg+xml
as of file 5.29: image/svg
former versions: text/plain

Note that file 5.38 has been released only two weeks ago, and that
we certainly won't switch back to the pre file 5.29 behavior.

Also note that active support for PHP 7.2 has ended one month
ago[1], so any fix for this could only go into PHP 7.3.

[1] <https://www.php.net/supported-versions.php>
 [2019-12-30 23:20 UTC] phpbugs-xap2kka at mpan dot pl
But on sloth’s system `file` returns a value different than PHP does. This is the primary reason for re-opening and claiming it to be a PHP bug, as far as I understand. Shouldn’t they both agree on a single system?
 [2019-12-30 23:25 UTC] bugreports at gmail dot com
sadly php has it#s own fork of file-libs
in theory you can rebuild "data_file.c"

in reality this works until the distribution has a to new file-libs and in that case the command suceeds but the resulting php binary is unusable

php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc > ext/fileinfo/data_file.c
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Thu Feb 27 15:01:28 2020 UTC