Conversation
I changed content-type of request to "application/octet-stream" if request didn't have content-type.
hsbt
force-pushed
the
removed-default-content-type
branch
from
683d0df to
fc5870d
Compare
|
I stumbled upon this after debugging a bug with an OIDC provider where the |
`faraday` and in turn `faraday-net_http` use `net-http` to make calls. Since 0.7.0[1], net-http does not set the Content-Type by default[2], which is fine but problematic for anyone who magically relied on that previous behaviour. Use the `:url_encoded` middleware fixes the problem by correctly setting the Content-Type header. 1: https://github.com/ruby/net-http/releases/tag/v0.7.0 2: ruby/net-http#207
`faraday` and in turn `faraday-net_http` use `net-http` to make calls. Since 0.7.0[1], net-http does not set the Content-Type by default[2], which is fine but problematic for anyone who magically relied on that previous behaviour. Use the `:url_encoded` middleware fixes the problem by correctly setting the Content-Type header. 1: https://github.com/ruby/net-http/releases/tag/v0.7.0 2: ruby/net-http#207
|
@freesteph I'd missed the importance of this change too...until one of my API clients broke. 😅 The changelog entry just didn't grab my attention until I figured out why my API calls broke. 😆 To be fair to this |
|
I added that section to https://github.com/ruby/net-http/releases/tag/v0.7.0 |
|
We had this change pulled in from a transitive dependency during a routine dependabot PR. Had no idea there was a breaking change because the main PR and changelog was for another library. Does this project not use semver? I thought breaking changes belonged in major version updates. And I've never heard of 0.6->0.7 being considered major - perhaps that's ignorance on my part! |
Yes, we don't follow that. |
|
5 participants
Fixes #205