php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #79045 Incorrect svg mimetypes detected
Submitted: 2019-12-30 01:30 UTC Modified: 2019-12-30 12:20 UTC
Votes:27
Avg. Score:3.8 ± 0.9
Reproduced:26 of 26 (100.0%)
Same Version:5 (19.2%)
Same OS:5 (19.2%)
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 Developer Edit
 [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

Pull Requests

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
 [2020-03-25 14:47 UTC] magnar at myrtveit dot com 
I also experienced this annoying issue today. Here is a very simple reproduction: https://3v4l.org/K2jqo
 [2021-07-19 10:17 UTC] tim at decorrespondent dot nl 
How is this still a problem after 2 years? The only solution now to properly handle svg files is to manually write an adapter so it will output `image/svg+xml`?
 [2021-11-22 22:44 UTC] sanya dot davyskiba at gmail dot com 
After short investigation found that issue related to outdated RFC3023 8.19, since it was added 20 years ago (Jan 2001) when the svg+xml standard not developed yet (see https://datatracker.ietf.org/doc/html/rfc3023#section-8.19), but after standard accepted in 2008 (https://www.w3.org/TR/SVGTiny12/) seems they haven't updated RFC3023:

> This media type registration is extracted from Appendix M of the SVG 1.2 Tiny specification.
https://www.w3.org/TR/SVGTiny12/mimereg.html

I have no idea why. Probably it was not so easy that time.

Later on in 2016 related issue for W3C SVG working group closed because of:

> This work is not in scope of the SVG working group for the next year.
https://github.com/w3c/svgwg/issues/266#issuecomment-262127579

and it refers to Web Incubator Community Group (WICG) who should take care of that, but it seems they are not, at least I haven't found related discussions (https://discourse.wicg.io/c/html/svg/15).

Many frameworks (not only all php frameworks, but also in other languages) who refers to RFC3023 sending wrong mime type to header, or they have their own ad-hoc fix to always send image/svg+xml.

For example, "file -i Test.svg" working well because they added svg+xml by default, see github.com/file/file/commit/1a08bb5c235700ba623ffa6f3c95938fe295b262

As conclusion: in my opinion it's quite strange situation since we rely on RFC which wasn't updated for two decades. And we sending all PHP-generated content to browsers which relies on different standard (i.e. w3c), so the question is: What exactly standard we must respect — outdated RFC3023 chapter 8.19 or W3C SVGTiny12?
 [2021-11-23 12:14 UTC] sanya dot davyskiba at gmail dot com 
The ones who want to use "image/svg+xml" must have to read https://hackerone.com/reports/148853, otherwise it is big security risk. That probably was the original issue, why by default we don't have this mime type auto-detected.
 [2024-07-22 05:47 UTC] jeffrey597doss at outlook dot com 
I was actually reading your article and found some really interesting information. The thing is quite clear that I just want to thank for it. (https://github.com)(https://www-panoramacharter.com)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 13:01:31 2024 UTC