Aws-cli: aws s3 sync on Windows wrongly sets Content-Type to text/plain for js files

[niwsa]

I have a linux build server where the s3 sync works as expected setting the Content-Type to application/javascript.But coming to windows server 2012 it does not work.

[kyleknap]

How the content type is detected is platform specific and can sometimes be controlled at the system level (you can do it for Ubuntu, but not sure about Windows). Otherwise, there is not really too many options to get around this other than setting the --content-type yourself. Ideally, we would allow users to plumb in their own content type detection. We have a tracking GitHub issue for this: https://github.com/aws/aws-cli/issues/1249. I would recommend tracking that issue as if we make mime types pluggable this should solve your issue. Let us know if you have any questions.

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[Kralizek]

I got the same issue again.

I created a simple Angular application, built in production mode, used the cli to sync the artifacts with a bucket. All the JS files had conte-type set to text/plain.

[ggallotti]

Same problem here.
Created an Angular Ap.p. Used aws cli s3 sync and all files have text mimetype.

[arpanmkjee]

same issue here

[moznuy]

Same issue here.
On Windows mime types are all text/plain.
On Linux it works as expected.

[moznuy]

Ok. I found where the problems most likely lies.

This is output from default installation of python3 on Ubuntu:
Python 3.6.8 (default, Aug 20 2019, 17:12:48) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_type('1.js')
('application/javascript', None)

And this is output from installation of python that comes with aws-cli on Windows:
Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_type('1.js')
('text/plain', None)

[moznuy]

Ok, so the problem probably lies even deeper.

So based on this:
Python mimetypes

on Windows, the current registry settings are loaded

And this implementation

It looks at HKEY_CLASSES_ROOT\.js in case of JS file. (Cached version of it).
So the problem in my case is that in HKEY_CLASSES_ROOT\.js Key Content Type Value is equal to text/plain. I don't know if it is the default value, or this value was set by any of the installed programs.

[Rastamas]

Quick and easy workaround if you don't want to (or can't) change the registry value is just to upload js files separately.

aws s3 sync <LocalPath> <S3Uri> --exclude `"*.js`" --delete

then

aws s3 sync <LocalPath> <S3Uri> --exclude `"*`" --include `"*.js`" --content-type application/javascript

[xsalazar]

Wow @moznuy you're spot on. I was struggling with this exact issue with Terraform running some local-exec blocks to copy files between S3 buckets. The files would be transferred over, but suddenly every .js file had its Content-Type rewritten from the original value in the original file. I tried every combination of --metadata, --metadata-directive, --no-guess-mime-type and I could not figure out why this was failing. Cutting out Terraform and running the AWS CLI directly changed nothing. I tried a similar approach to @Rastamas, but we were using the additional --metadata-directive REPLACE tag that forces AWS to only apply the metadata values passed in through the CLI.

Ended up being the incorrect Registry value. I can only guess that installing some editor or changing the default editor for .js files in Windows somehow corrupted this key. The commands worked in almost all other scenarios since we spin up fresh images, but my local machine was totally wrong.

[odyth]

It seems aws cli pulls the content type from HKEY_LOCAL_MACHINE\Software\Classes.js and for me on windows server 2016 this was set to text/plain. Interestingly though HKEY_CLASSES_ROOT.js was set to application/javascript. Changing HKEY_LOCAL_MACHINE\Software\Classes.js to have a content type of application/javascript resolved the issue for me.