Support additional mime types

[thoughtbot]

Support additional mime types

[qrush]

Comments from S. Brent Faulkner:

Not directly intended to fix this but a patch I submitted for resolution to #144 adds support for Rack::Mime (if loaded)... this commit adds many extra mime types...

http://github.com/sbfaulkner/paperclip/commit/dd773d20d3fc555f48440c5aa6130af565df448b

[qrush]

Comments from Sam Stokes:

Relatedly, I needed Paperclip::Upfile to know about the application/pdf MIME type, so this one-line commit 89dcdd50... adds that. It also demonstrates that it's really easy to add new MIME types.

My understanding is that Paperclip::Upfile's ability to guess the content type doesn't normally get used, because if you upload something from a web form, then the browser supplies the content type and Paperclip just uses that. So this mostly comes up during testing (e.g. using webrat to fake out the browser).

Also (sorry for the double post but this might be useful to some people), here's a quick and dirty monkey-patch to stick in a suitable place (like features/support/env.rb) if you need to quickly add a new content-type.

[qrush]

Comments from Paul Cortens:

This line of code in storage.rb sets the content-type on S3 to the content-type of the originally uploaded file. If the file has been converted to another image format, this is not accurate.

key.put(nil, @s3_permissions, {'Content-type' => instance_read(:content_type)})

I am guessing that we could use a method similar to content_type in upfile.rb to detect the correct content type from the format specified in the style hash. Or we could have an option to explicitly set the content-type for each style in the style hash.

What do you think?

I made a fork (http://github.com/korobkov/paperclip), where I I've added support for MIME-type resolution by magic, rather than extension, using http://github.com/minad/mimemagic gem.
It was written on pure ruby, so it will also work on non-posix-compliant systems without /usr/bin/file utility.

[masterkain]

still no love..

I've switched MIME-type resolution from http://github.com/minad/mimemagic to http://github.com/Narnach/file_wrapper, which wraps /usr/bin/file...

[monde]

I implemented correct content_type detection with file --mime-type command:
http://github.com/monde/paperclip/commit/2ca52df1aa45a8a9cb3d086a6be77168b7f5be52

The file command is able to determine a wide range of content types beyond what is possible with a simple check of a file name's extention.

[jyurek]

monde, I've pulled that last patch into master.

Thanks! It's better.
But I still not understand, what is the reason to have some MIME-types hardcoded while having content_type detection with file --mime-type command? Or why not just to rely on some gem-wrapper on file command (like http://github.com/Narnach/file_wrapper)?

[monde]

I assume that @jyurek pulled my feature into the codebase because it maintains the original functionality and provides a reliable back up when the default fails to identify the content-type. Personally I would prefer just delegating the whole thing to the underlying exec of file --mime-type since it is the most all knowing application of this type in the world. The file_wrapper gem is already doing what my patch was doing by calling file --mime-type, but my patch does it in the "Paperclip Way" and in turn doesn't introduce the file_wrapper dependency.

[jyurek]

Basically, what monde said. I may revisit the situation later, however.

[masterkain]

I would not prefer to entirely delegate because using file --mime-type along is getting dangerous.

For example I have two perfectly valid mp3s, one is correctly identified by the file command as audio/mpeg, the other one as application/octet-stream.

I checked for a new version of file command but it doesn't resolve the issue.