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.

[bnbon]

+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_MACHINE\Software\Classes.js and for me on windows server 2016 and windows 10 this was defaulted to text/plain. Changing HKEY_LOCAL_MACHINE\Software\Classes.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_MACHINE\Software\Classes.js and for me on windows server 2016 and windows 10 this was defaulted to text/plain. Changing HKEY_LOCAL_MACHINE\Software\Classes.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.

[liesislukas]

/etc/mime.types has font/woff mime type:

using code build to build the app artifact is uploaded to s3 by aws itself

yet inside s3 mime type is broken. file fa-solid-900.woff

issue here is probably is not about the mime file, while file is inside ubuntu box code build uses to build the artifact, but the artifact is uploaded by code build service and that service is probably not using the mime file

---- update

worked around by not spiting out artifact out of code build but just uploading to s3 directly from build machine and while it's ubuntu with correct /etc/mime.types file uploaded to s3 now knows correct mime types.

[eboboshka]

It's very strange that the error has remained relevant since 2015! Used AWS S3 CLI to just copy static landing pages into S3 and kept getting this weird problem with webp & ttf files (binary/octet-stream)

This adds even more questions that the AWS client didn't add normal MIME handling, since AWS CloudFront is very demanding on Content-Type for compression to work properly - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html#compressed-content-cloudfront

For readers who come from google: AWS S3 webp binary/octet-stream RFC6838, RFC4855, RFC6838 - https://www.iana.org/assignments/media-types/media-types.xhtml

[michaelperret]

Apart from updating the underlying mime.types file is there any solution for this past specifying the --content-type flag? The guessed mime-type process is fantastic except for the unique case of woff and woff2 behind Cloudfront.

Are there any plans to address this @tim-finnigan?

[tim-finnigan]

@michaelperret I don't have any updates as far as plans at this time. There are workarounds as mentioned in this issue. The team is still tracking this feature request in their backlog and will prioritize addressing it accordingly.