I had an issue where the
AWS CLI wasn’t guessing the content-type of SVG files correctly on sync and was setting them to
application/octet-stream - the default “I don’t know” mimetype.
There’s a proper fix to make the mimetype guessing work here. This is a quick fix for stuff that’s already been uploaded to s3:
$ aws s3 cp --exclude "*" --include "*.svg" --content-type = "image/svg+xml" --metadata-directive = "REPLACE" --recursive --acl public-read ./output/ s3://<bucketname>
probably wipes out some of the other metadata on the files, but sets
acl correctly for uploading
SVG files to a website hosted on s3. Note:
I found out later that this was affecting more files
& filetypes than I thought, so the simplest fix was to delete everything in the bucket and re-upload it, after fixing the . AWS CLIs content type guessing
The content-type guessing done by AWS CLI is based on the mimetype definitions available on your system. You can improve the mimetype guessing by updating these definitions.
cssmin is unmaintained & has a bug with complex :is selectors
You can use the new CSS :is selector to write complex CSS selectors in a much more compact way
How apy keys work, what .source files are and how to fix Key is stored in legacy trusted.gpg keyring Warnings