Edit report at https://bugs.php.net/bug.php?id=79045&edit=1
ID: 79045
Comment by: sanya dot davyskiba at gmail dot com
Reported by: sloth at 0k dot vc
Summary: Incorrect svg mimetypes detected
Status: Open
Type: Bug
Package: Filesystem function related
Operating System: Centos 7.5
PHP Version: 7.2.26
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2021-11-22 22:44:09] 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-07-19 10:17:58] 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?
------------------------------------------------------------------------
[2020-03-25 14:47:26] magnar at myrtveit dot com
I also experienced this annoying issue today. Here is a very simple reproduction: https://3v4l.org/K2jqo
------------------------------------------------------------------------
[2019-12-30 23:25:11] 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
------------------------------------------------------------------------
[2019-12-30 23:20:49] 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?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=79045
--
Edit this bug report at https://bugs.php.net/bug.php?id=79045&edit=1