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
I then discovered that the fix was only valid locally, and AWS uploads were still failing. Fixed in fix SVG thumbs on AWS #789.
Now, I find that even though files upload correctly, Amazon S3 does not supply the correct Content-Type header for SVG files. This makes them unusable in <img> tags.
There is an option to suppy a Content-Type when uploading to S3. I can make it work using two hooks, like so:
defon_uploader(args)args[:aws_settings][:aws_file_upload_settings]=lambda{ |settings|
@suppress_content_type ||= falsesettings[:content_type]=params.dig("file_upload")&.content_typeunless@suppress_content_typesettings}end# This is needed to prevent using 'svg+xml' content type being applied to resized images, which are JPGsdefuploader_aws_before_upload(_args)@suppress_content_type=trueunless_args[:key].match?/\.svgz?\z/end
But that still leaves SVG use through AWS not working by default. Plus, if SVGs need a Content-Type applied when uploading to S3, it seems likely that some other file types will need one as well. I think this option should be passed by default.
Since my last two PRs about this haven't completely solved the problem, I'm filing this issue to get comments before attempting another one. Any thoughts on how this should be handled?
The text was updated successfully, but these errors were encountered:
@texpert I'm not so sure. So far I've only had this problem with SVGs, but it could theoretically happen with other file types I haven't tried. (Probably not with images though, since the image formats used in browsers don't change much.) So we could end up with additional hacks for other file types if we put this in.
Then again, I'm probably worrying too much about hypotheticals, since you and I are the only ones seeing this issue after 2.5 years :)
Yes, @brian-kephart , ideally the Content-Type should be always applied, both for the main files, and also for the thumbnails.
But your solution will be good for now!
As for the future, it would be good to implement into Camaleon a 3rd party file attachment toolkit solution. Despite of of the Active Storage being a Rails component, I would prefer Shrine, as a more flexible, mature and lightweight solution.
Recap:
Now, I find that even though files upload correctly, Amazon S3 does not supply the correct
Content-Type
header for SVG files. This makes them unusable in<img>
tags.There is an option to suppy a
Content-Type
when uploading to S3. I can make it work using two hooks, like so:But that still leaves SVG use through AWS not working by default. Plus, if SVGs need a
Content-Type
applied when uploading to S3, it seems likely that some other file types will need one as well. I think this option should be passed by default.Since my last two PRs about this haven't completely solved the problem, I'm filing this issue to get comments before attempting another one. Any thoughts on how this should be handled?
The text was updated successfully, but these errors were encountered: