Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Troubles with SVGs on AWS (again) #794

Open
brian-kephart opened this issue Apr 4, 2018 · 3 comments
Open

Troubles with SVGs on AWS (again) #794

brian-kephart opened this issue Apr 4, 2018 · 3 comments
Milestone

Comments

@brian-kephart
Copy link
Collaborator

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:

def on_uploader(args)
  args[:aws_settings][:aws_file_upload_settings] = lambda { |settings|
    @suppress_content_type ||= false
    settings[:content_type]  = params.dig("file_upload")&.content_type unless @suppress_content_type
    settings
  }
end

# This is needed to prevent using 'svg+xml' content type being applied to resized images, which are JPGs
def uploader_aws_before_upload(_args)
  @suppress_content_type = true unless _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?

@texpert
Copy link
Collaborator

texpert commented Oct 17, 2020

Thanks, @brian-kephart , works like a charm - texpert/florsan@924424e

Sure this options should be passed by default!

@brian-kephart
Copy link
Collaborator Author

@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 :)

@texpert
Copy link
Collaborator

texpert commented Oct 21, 2020

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.

@brian-kephart brian-kephart added this to the Version 3 milestone Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants