Bug #76543 [Com]: mime_content_type returns false mimetype for svg files

Edit report at https://bugs.php.net/bug.php?id=76543&edit=1 ID: 76543 Comment by: ilya at taotesting dot com Reported by: michael dot wolfram at smart-webwork dot de Summary: mime_content_type returns false mimetype for svg files Status: Not a bug Type: Bug Package: *Directory/Filesystem functions Operating System: Ubuntu 18.04 LTS PHP Version: 7.2.5 Block user comment: N Private report: N New Comment: As a at b dot c dot de it still appears to be a bug, because if using output of mime_content_type/finfo stuff as a thingy to put in Content-Type header - latest versions of chromium/firefox refuse to show such images. At least in cases when there are more than one images in single SVG file, when it's only one image in a file - those two browsers correctly show the images even with image/svg Content-Type header. Previous Comments: ------------------------------------------------------------------------ [2018-06-30 02:28:11] a at b dot c dot de RFC3203 and its successor, RFC7303, say only that using "+xml" is optional (though it SHOULD be used for XML media types) only for purposes of *registration* (that is, SVG, being an XML type, could have been registered as image/svg+xml, or as image/svg). It doesn't say that, once "image/svg+xml" is registered, "image/svg" is also acceptable. Nothing says users of registered media types can discard suffixes at will. The idea being that XML processors can be assured that they can parse "foo/bar+xml" documents (and JSON processors can parse "foo/bar+json"), but they can't have such an expectation about "foo/bar". Since W3C only registered "image/svg+xml", "image/svg" isn't a registered media type. https://www.iana.org/assignments/media-types/media-types.xhtml#image https://www.w3.org/TR/SVG/mimereg.html Still, as noted, this bug report should be bumped upstream. ------------------------------------------------------------------------ [2018-06-29 11:27:59] ab@php.net Thanks for the report. The mimetype command is based on the freedesktop data, which uses different patterns. The provided file doesn't contain the xml declaration, thus libmagic decides it's not necessary a xml file. The RFC 3023 tells so far, the mime type SHOULD contain "+xml" suffix. https://tools.ietf.org/html/rfc3023#section-8.19 And the XML 1.0 spec say, a document SHOULD include the xml declaration. As for me, what libmagic does is consequent, as it still shows it could recognize the file to be SVG, but it cannot guarantee it's XML. Given RFC 3023 doesn't forbit the absense of the suffix, this seems ok. If this should be fixed, then in libmagic itself, so this should be reported there. Thanks. ------------------------------------------------------------------------ [2018-06-28 23:00:03] michael dot wolfram at smart-webwork dot de set php version ------------------------------------------------------------------------ [2018-06-28 22:58:55] michael dot wolfram at smart-webwork dot de Description: ------------ function mime_content_type return false MIME-Type for a svg file. It returns image/svg instead of image/svg+xml. The function mimetype on ubuntu bash on same host returns the correct mimetype. PHP configuration: PHP 7.2.5-0ubuntu0.18.04.1 (cli) (built: May 9 2018 17:21:02) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.2.5-0ubuntu0.18.04.1, Copyright (c) 1999-2018, by Zend Technologies Test script: --------------- on ubuntu bash $ wget https://framework.zend.com/img/zend-framework-logo.svg // correct mimetype with bash function mimetype $ mimetype -M zend-framework-logo.svg // incorrect mimetype with php $ php -r 'echo mime_content_type("zend-framework-logo.svg");' Expected result: ---------------- image/svg+xml Actual result: -------------- image/svg ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=76543&edit=1