Tempfile and @content_type assignment

[Rendez]

Hi,

I would like to open the conversation on a closed issue for a new angle of discussion #284 :

My app am using Rack::Multipart module, as part of a Sinatra-based app (Padrino TBS). As processed by the Multipart parser: https://github.com/rack/rack/blob/master/lib/rack/multipart/parser.rb#L226 we obtain a Hash containing :type, instead of :content_type. This is fine Rack behavior, but it messes completely with the way Carrierwave decides to assign a content_type to a file, when an instance of SanitizedFile is created: https://github.com/carrierwaveuploader/carrierwave/blob/master/lib/carrierwave/sanitized_file.rb#L287

This causes the assignment of content_type to result in value "" or nil, depending (empty in any case).

Plus when later the cached file is read, SanitizedFile tries to determine the content_type via the Mime Type Gem, traditionally a name of a cached file in FS does not contain the extension anymore, as to the Tempfile instance Rack creates. What this causes is that storing the upload via FOG (aws in my case) would not send any content-type headers, and AWS does not recognize for example SVG files automatically. They are uploaded, but not delivered later with the right Content-Type (image/svg+xml) header but rather text/plain.

I've resorted to adding :content_type to the hash prior to creating my ActiveRecord instance

    params[:file][:content_type] = params[:file][:type]
    @upload = Upload.new(file: params[:file])

Which solves the issue, but as I don't have a lot of expertise with Carrierwave, I would like to throw the first stone to propose what would be the best way to address this issue involving Rack Multipart, Carrierwave's caching-first strategy, and AWS content_type setting.

[bensie]

Fixed! Please give master a try and report back if you still see this issue.

[Rendez]

@bensie works! Thanks a lot.