put_object fails to honour overridden extra_headers and content-disposition

[brycied00d]

In debugging why Backblaze wasn't honouring the content_disposition I was passing to put_object I noticed that its Hash#merge is taking in a Hash that's indexed by symbols (the {'foo': 'bar'} syntax) and merging in a hash that's indexed by strings ({'foo' => 'bar'}) and as a result, user-defined Content-Type doesn't override the default b2/x-auto

This behaviour can be seen in the logger.debug output from the request body where there's both :"Content-Type" and "Content-Type", then look at the response contentType of application-octet stream which indicates that b2/x-auto had been used. You will also notice :Authorization and "Authorization" headers which is the result of the same mis-match between the use of the symbol :Authorization in put_object and the use of a string Hash index in b2_command. (Formatting is my own to make the lines easier to read)

# Request body
{:body=>"-- Body 597185 bytes --", 
 :headers=>{:Authorization=>"<redacted>",
 :"Content-Type"=>"b2/x-auto",
 :"X-Bz-File-Name"=>"<redacted>",
 :"X-Bz-Content-Sha1"=>"857b96203ddfa5c50052c003a3db08d20cb2fc35",
 "Content-Type"=>"text/plain",
 "X-Bz-Info-src_last_modified_millis"=>1563222099031,
 "Authorization"=>"<redacted>"}}

# API response
{"accountId"=>"b8597a332ec1",
 "action"=>"upload",
 "bucketId"=>"<redacted>",
 "contentLength"=>597185,
 "contentSha1"=>"857b96203ddfa5c50052c003a3db08d20cb2fc35",
 "contentType"=>"application/octet-stream",
 "fileId"=>"<redacted>",
 "fileInfo"=>{"src_last_modified_millis"=>"1563222099031"},
 "fileName"=>"<redacted>",
 "uploadTimestamp"=>1563236520000}

https://github.com/fog/fog-backblaze/blob/f45d37606e937bdef2a5d59a1364a57a0f1f4c42/lib/fog/backblaze/storage/real.rb#L214-L219

[owexroasia]

what's the status of this issue?

[gagoit]

@Paxa It's fixed in the pull #15 , but after that it's overwritten by this commit
https://github.com/fog/fog-backblaze/commit/83adba05e3a0ee5f91b5ff7c8cd7049700cbbb69 I've created the new pull #28 to fix it (copied from #15). Please help us to check it again. Thank you!