idea: s3 module to auto detect content type and set as metadata

[Jake Clarkson]

Hi all,

I'm in the process of uploading our static assets to S3 via an ansible task.

As this bucket is going to be sitting behind Cloudfront I really need the Content-Type HTTP response header to be set correctly.

Instead of us all having to do this manually every time (via the metadata property of the task) how about if the s3 module did this automatically? Something like:

```

- name: upload images to s3 bucket

  s3: bucket=my_bucket object={{ item }} src={{ item }} mode=put

  with_fileglob:

    - web/images/*.png

```

And then have this adding in some metadata of "Content-Type: image/png" automatically. There could be an option for something like 'infer_content_type' which could default to false.

Happy to have a crack at it if people think it's worth it :-)

Thanks,

Jake

[Michael DeHaan]

We'd be open to a pull request on this subject I guess. 

Would it run "file" against the tool to figure out the type?  This doesn't map 100% to MIME types, so curious how you'd go about it.

Extensions shouldn't be made to be significant, IMHO.   That's a little old-school-windowsey.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/8d20e617-7ddf-429b-bbd5-0ca542a8a26c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Drake Wilson]

On 26/08/14 18:00, Michael DeHaan wrote:
> Extensions shouldn't be made to be significant, IMHO. That's a little old-school-windowsey.

That's still in very widespread use, and not only in Windows-based environments, and it's vastly
more robust than trying to deal in potentially-colliding magic numbers; e.g., the latter means
hooking up to existing preprocessing systems that attempt to ensure that all output files will
be interpreted within a restricted set of types by name becomes impossible. ("widespread" here
includes things like Apache and nginx both frequently being configured to use such a mapping
by default.)

Filesystem-level extended attributes would be cleaner than encoding in the name, but are less
convenient to output in a lot of environments. magic(4) (including file(1)) could be really
dangerous here; you might be able to play around with filtering the set of recognized types,
but egh.

Modern GNU/Linux machines often have /etc/mime.types, which maps extensions to media types.

---> Drake Wilson

[Michael DeHaan]

"That's still in very widespread use"

Yes, I'm aware people use file extensions.  What I'm saying is you can't trust them :)

" and it's vastly
more robust than trying to deal in potentially-colliding magic numbers"

Which is why we request you pass the type :)

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/53FD1582.3030303%40dasyatidae.net.

[Jake Clarkson]

Thanks for the responses guys. Although in my use case the extension can be trusted I agree to make it publicly available in S3 may lead to some confusion :-)