You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some optimization tools e.g. to compress SVG images removing the XML encoding line <?xml version="1.0" encoding="UTF-8"?>. Without this line, PHP function finfo_open() detects the file as image/svg instead of image/svg+xml. It seems this is a know bug which is described here: https://bugs.php.net/bug.php?id=79045
Problem Part 2
Uploading such image to AWS S3 will trigger the browser to download the image instead of show it inside the website. The reason is, that during the upload process the wrong content-type image/svg is explicit set for the S3 object by PHP.
Solution
A simple solution could be to add a clean-up function for the content-type. The following method was tested and works like expected (means: the correct content-type for SVG images without encoding line is set during the upload and successfully shown inside the website):
// line 45
'ContentType' => $this->cleanMimeContentType($contentType),
// ...
/**
* Fix wrong MIME detection by PHP for SVG images (see https://bugs.php.net/bug.php?id=79045)
* @param string $contentType
* @return string
*/
private function cleanMimeContentType (string $contentType): string {
if ($contentType === 'image/svg') {
return 'image/svg+xml';
}
return $contentType;
}
Edit (2021-07-20):
The newest TYPO3 release implements a SVG Sanitizer (TYPO3/typo3@45b389d44d), which might check (and/or fix?) "invalid" files. I'll report here after having more information and close this issue in case it works.
The text was updated successfully, but these errors were encountered:
Hi @Moongazer
It's a while ago.
I merged #141 today and tried to reproduce the problem you described. On my current setup which also uses Cloudfront uploaded the stripped svg '' was added.
Can you check if there is still a problem? For me it looks good.
Problem Part 1
Some optimization tools e.g. to compress SVG images removing the XML encoding line
<?xml version="1.0" encoding="UTF-8"?>
. Without this line, PHP functionfinfo_open()
detects the file asimage/svg
instead ofimage/svg+xml
. It seems this is a know bug which is described here: https://bugs.php.net/bug.php?id=79045Problem Part 2
Uploading such image to AWS S3 will trigger the browser to download the image instead of show it inside the website. The reason is, that during the upload process the wrong content-type
image/svg
is explicit set for the S3 object by PHP.Solution
A simple solution could be to add a clean-up function for the content-type. The following method was tested and works like expected (means: the correct content-type for SVG images without encoding line is set during the upload and successfully shown inside the website):
./aus_driver_amazon_s3/Classes/S3Adapter/MultipartUploaderAdapter.php:
Edit (2021-07-20):
The newest TYPO3 release implements a SVG Sanitizer (TYPO3/typo3@45b389d44d), which might check (and/or fix?) "invalid" files. I'll report here after having more information and close this issue in case it works.
The text was updated successfully, but these errors were encountered: