Aws-cli: aws s3 sync doesn't guess MIME type for .woff file

[Janpot]

I'm syncing an assets folder to S3 to be served over CDN. I noticed that .woff files get Content-Type: binary/octet-stream instead of application/font-woff.

[bonbonio]

+1 for this.

[azoff]

+1

[j]

+1 (and for other font types)

[azoff]

For now I'm using this: https://github.com/dailymuse/s3-content-type-fixer

[wilsonwc]

This looks like it's actually a limitation of the Python mimetype library, maybe the code needs to be augmented to support mime types that aren't defined in that library?

[jamesls]

Yes, and internally I believe it will look at /etc/mime.types and a few other locations to get these mappings, so a temporary workaround would be for people to update that file if possible.

Otherwise I think there's two options here:

1. We can either start an additional list within the AWS CLI code based that has additional extensions->mimetype mappings.
2. We can look for and load an optional mime.types file. Say if you were to create an ~/.aws/cli/mime.types file, we would load that file and use that in addition to /etc/mime.types.

Any preferences for either approach?

[wilsonwc]

Thanks for the reply. It looks like Apache maintains an updated list that would be the same format as the /etc/mime.types. This might be appropriate to link to or include to satisfy the first option, and then still give users the ability to add/override types in a ~/.aws/cli/mime.types file as a new feature.

http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=markup

[wilsonwc]

I can also confirm that replacing my /etc/mime.types with the file linked above fixed the issue for me as a temporary workaround. (Using CentOS 6)

[dbinetti]

@jamesls @wilsonwc Are there any plans to to add support for the ~/.aws/cli/mime.types approach? This would be most welcome.

[ASayre]

Good Morning!

We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.

This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.

As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.

We’ve imported existing feature requests from GitHub - Search for this issue there!

And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.

GitHub will remain the channel for reporting bugs.

Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-The AWS SDKs & Tools Team

[jamesls]

Based on community feedback, we have decided to return feature requests to GitHub issues.

[veloper]

For those using Ubuntu (at least 14.04) it looks like you can add a personalized list of mime types to your home directory that will override the system's /etc/mime.types file.

Per the docs in the /etc/mime.types file:

#  Users can add their own types if they wish by creating a ".mime.types"
#  file in their home directory.  Definitions included there will take
#  precedence over those listed here.

So, you can script some individual replacements like...

echo "font/woff woff" >> ~/.mime.types
echo "font/woff2 woff2" >> ~/.mime.types

Or, just do the whole _kit-and-caboodle_ wrapping @wilsonwc 's solution...

curl -s "http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=co" > ~/.mime.types

Happy coding & orchestrating!

[theory]

I fixed my issue by editing /etc/apache2/mime.types on my Mac, but it would be nice to be able to specify a file that one can use to add additional type mappings for a run of aws sync.

[75lb]

On my macbook, the aws s3 sync command incorrectly guesses that an index.mjs file should have the MIME type binary/octet-stream. This breaks my web app - the correct MIME type should be application/javascript.

What is the currently recommended way to override the MIME type guessed by aws s3 sync on a mac?

[JJC1138]

For me on Ubuntu 18.04.1 LTS aws s3 sync didn't make use overrides that I put in ~/.mime.types, but did make use of ones that I put in the system-wide /etc/mime.types using e.g:

echo "video/mp4 m4v" | sudo tee -a /etc/mime.types

[odyth]

For those on windows aws cli pulls the content type from HKEY_LOCAL_MACHINESoftwareClasses.js and for me on windows server 2016 and windows 10 this was defaulted to text/plain. Changing HKEY_LOCAL_MACHINESoftwareClasses.js to have a content type of application/javascript resolved the issue for me.

[clearwaterstream]

For those on windows aws cli pulls the content type from HKEY_LOCAL_MACHINESoftwareClasses.js and for me on windows server 2016 and windows 10 this was defaulted to text/plain. Changing HKEY_LOCAL_MACHINESoftwareClasses.js to have a content type of application/javascript resolved the issue for me.

Thank you. I had to do it for javascript and the woff files. I am not sure if AWS sync tool should be modifying those registry keys on Windows. Perhaps and it could, like on Linux system, pull the info from mime.types file. Since that file on Windows does not exist, upon first run the tool can create it, taking cues from the registry ...

[augustoproiete]

I'm seeing this same issue using aws s3 sync on Windows, where Javascript files are not being set with the correct mime type which makes scripts to be blocked by browsers.

I double-checked the Registry:

• HKEY_CLASSES_ROOT\.js
• HKEY_LOCAL_MACHINE\Software\Classes\.js

And in both cases the Content Type value is set to application/javascript, yet this mime type is not set in the S3 bucket.