[Informative] net-http 0.7.0 indirectly breaks HTTParty - default content-type removed.

[danlo]

Greetings,

The new version of net-http 0.7.0 breaks HTTParty indirectly. Here is the releases change log: https://github.com/ruby/net-http/releases

Default Content-Type Removed

The default behavior of automatically setting the Content-Type header to application/x-www-form-urlencoded for requests with a body (e.g., POST, PUT) when the header was not explicitly set has been removed.

For us we found out about this for the below code:

      response = HTTParty.post(
        'https://www.google.com/recaptcha/api/siteverify',
        body: encoded
      )

In this case, google was expecting: 'Content-Type: application/x-www-form-urlencoded'

Changing our code to this fixed the issue:

      response = HTTParty.post(
        'https://www.google.com/recaptcha/api/siteverify',
        headers: { 'Content-Type' => 'application/x-www-form-urlencoded' },
        body: encoded
      )

No action is requested, this is just to inform you.

[robotfelix]

Arguably the change to net-http has a knock-on effect of making the behaviour of this gem a bit inconsistent.

Looking at one of the basic examples:

https://github.com/jnunemaker/httparty/blob/5c8b45e6297d181d99a56f5297dade3e358cc6f9/examples/basic.rb#L18-L28

This gem has the default behaviour of converting the provided body (a ruby Hash) to a URL encoded body, but does not set a Content-Type header to match the body. Under the RFC quoted at the top of the net-http issue a recipient may assume that the body is an octet stream, which isn't appropriate here.

The default behaviour of this gem used to neatly match the default behaviour of net-http, but going forward this gem should probably consider setting the Content-Type when a ruby Hash is passed in like this.

[jnunemaker]

@danlo @robotfelix how does https://github.com/jnunemaker/httparty/pull/828 look?