Closed avgerin0s closed 4 years ago
Forgot to mention the maintainers as the README
suggests.
cc @dhague, @Ladas, @seanhandley, @mdarby and @jjasghar.
Build succeeded.
Any news on this one?
Looks good to me :+1:
@aufi Thanks for merging this. Are there any plans for a patch version release any time soon?
I don't have permissions to create a new gem release, but there few new things, so it would make sense to me :+1:
@Ladas Would it be possible create a new release?
Hope you are well and healthy. Any news on the upcoming release?
@ares are you planning new release soon?
let me forward this question to @domitea, is there already something you want to push? I can do the release if not
@ares Nothing right now.
ok, 1.0.11
released, I hope I didn't forget anything
We are using the 1.011 gem and the issues #501 and #502 are not fixed. Everything newly created is "application/json" no matter what content_type= we are setting.
Any ideas?
@nhh Do you have a sample request/snippet of code that reproduces it?
@avgerin0s I'm using it with carrierwave, so there is no direct fog-openstack code. It may be a problem with carrierwave too, but #501 and #502 sounds pretty much like my problem.
CarrierWave::Storage::Fog::File
Calling the CarrierWave::Storage::Fog::File#content_type=
method has no effect. It seems that the Fog::Storage::OpenStack::File
has no method like #content_type=
. Or #metadata=
. What is the appropriate method to set the content_type?
@avgerin0s I've opened a more detailed issue on carrierwave. It may be useful for you?
https://github.com/carrierwaveuploader/carrierwave/issues/2484
I dont know what gem causes this issue, so sorry for the confusion.
This PR fixes #507 and potentially #501 and #502
Since f72d2fc (first released in v0.1.20) fog-openstack mutates the params passed on
Fog::Openstack::Core#request
by calling#delete(:headers)
1 on the params hash to access it.In case of a re-authentication the request is re-issued2 but the headers hash is no longer present. As a result all headers passed by the user are lost and the request gets just the default headers3.
This commit fixes the aforementioned behavior by not mutating the params hash in order to access its
:headers
part.