Skip to content

Conversation

@zygzagZ
Copy link

@zygzagZ zygzagZ commented Nov 6, 2025

httparty does properly set multipart content type when dealing with files or multipart url bodies. There was no default for urlencoded.

net-http 0.7.0 stops defaulting content type to x-www-form-urlencoded (net-http PR #207, issue #205). HTTParty encodes body with urlencode by default, but does not set content-type. HTTParty's default behavior of urlencoding needs to set content type.

changes in this pr:

  • default content type is set when implicitly encoding body as urlencode, as before with multipart
  • content type default is not used when set or when using custom query_string_normalizer.

If you use custom query_string_normalizer, return content_type as a second argument or pass a Content-Type header

httparty used to properly set multipart content type when dealing with files or multipart url bodies. There was no default for urlencoded.

net-http 0.7.0 stops defaulting content type to x-www-form-urlencoded (net-http PR jnunemaker#207), thus httparty's default behavior of urlencoding needs to set content type.
Content type does not get set when passed or when using custom query_string_normalizer.

If you use custom query_string_normalizer, return content_type as a second argument.
params.respond_to?(:to_hash) && (force_multipart || has_file?(params))
end

def content_type
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it acts as a getter when set, and tries to calc when body is not yet evaluated.

Comment on lines +19 to +24
if multipart?
@content_type = "multipart/form-data; boundary=#{boundary}"
generate_multipart
else
normalize_query_and_set_content_type(params)
end
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

useless change

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cus generate_multipiart sets @content_type, too

@dentarg
Copy link

dentarg commented Jan 6, 2026

Solved by #828?

@zygzagZ
Copy link
Author

zygzagZ commented Jan 8, 2026

I don't think #828 is a good PR, as it tries to guess content type based on whether body responds to some method and whether or not it was already set. HTTParty decides what gets sent. You can't really send a hash through a network. Hash is a ruby object. You send a string of bytes. The encoding is in there somewhere, done by HTTParty. Why guess when you can be sure. Set it exactly when encoding. This is what this pr does.

@marelons1337
Copy link

Can we get this merged? As it does actually seem like a better idea than #828

@jnunemaker
Copy link
Owner

#828 already solved the problem with a minimal, non-breaking fix. This would be a breaking fix, correct? custom query_string_normalizer must now return [query, content_type] tuple?

@zygzagZ
Copy link
Author

zygzagZ commented Jan 8, 2026

I meant it to be backwards compatible. It does not raise, but it assigns @content_type = nil and later sets Content-Type header to nil. This probably causes content-type to not be sent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants