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.
How to use an existing instance of a browser to debug in VSCode - instead of always launching a new one, or use debug in Brave.
How to use git hashes - or other environment variables in Vite & Vue 3
cssmin is unmaintained & has a bug with complex :is selectors