Don't alter Content-Type in Request if user explicitly sets it (#184)

[EPNW-Eric]

I'm using this library and came across a very frustrating bug, see #184.
The core problem is, that this library alters the Content-Type header I (as a developer) explicitly set.
This is dangerous behaviour and should be removed.

[kevmoo]

CC @brianquinlan @devoncarew – let's be careful with any change here. This has been "the way it is" for a very long time.

[EPNW-Eric]

CC @brianquinlan @devoncarew – let's be careful with any change here. This has been "the way it is" for a very long time.

Yes, it's been this way for years, despite the original issue beeing labeld as type-bug...
An other idee for solving this without breaking compability would be introducing a new, optional bool appendCharsetIfNotSet (defaulting to true) to the Request constructor and change

http/pkgs/http/lib/src/request.dart

Line 96 in 805a147

} else if (!contentType.parameters.containsKey('charset')) {

to something like

  } else if (!contentType.parameters.containsKey('charset') && appendCharsetIfNotSet) {

[DHMG-Git]

CC @brianquinlan @devoncarew – let's be careful with any change here. This has been "the way it is" for a very long time.

Yes, it's been this way for years, despite the original issue beeing labeld as type-bug... An other idee for solving this without breaking compability would be introducing a new, optional bool appendCharsetIfNotSet (defaulting to true) to the Request constructor and change

http/pkgs/http/lib/src/request.dart

Line 96 in 805a147

} else if (!contentType.parameters.containsKey('charset')) {

to something like

  } else if (!contentType.parameters.containsKey('charset') && appendCharsetIfNotSet) {

I completely agree. This exact behaviour makes it impossible to use this package for API calls to a filemaker server because the server rejects the sneakily added extra header.
This is especially annoying if you are using an app like FlutterFlow, where you have no influence over the default behaviour of packages, which makes it necessary to write everything in custom code, which negates the whole purpose of using such a tool in the first place.
Please fix this issue or add an optional property that disables this behaviour like suggested by EPNW-Eric.

[gnprice]

It turns out that the automatic setting of a charset in Content-Type can be avoided by not setting the body property, and instead setting bodyBytes.

This was observed last year in the #184 thread, and documented in #1014. See docs:
https://pub.dev/documentation/http/latest/http/Request/body.html

So that seems like a pretty reasonable way to avoid setting a charset.

And conversely, it seems pretty appropriate that if you do choose to set body rather than bodyBytes, then that would set a charset in the Content-Type header. After all, the one other thing that the body setter does apart from set bodyBytes is that it uses the request's encoding to turn the given string into bytes. So if the bytes you're putting in the request truly aren't encoded in that charset, then using the body setter doesn't make a lot of sense conceptually anyway.

Given that, I think it'd be appropriate to close this issue as resolved (by the documentation PR #1014), just as #184 was resolved.

[kevmoo]

See notes from @gnprice – feel free to push back

[ThexXTURBOXx]

This discussion is in fact already a year old, but I would like to warm it up again:
I have spent hours debugging this issue yesterday only to find out that it is not my code that is at fault here.

In fact, from a user perspective, the documentation is not very insightful in this case:
I was using the simple Client#post function to send a application/x-www-form-urlencoded body to a server.
The documentation for Client#post does not mention anything about the encoding being added to the Request.
It's actually the opposite - as a user, this documentation would 100% lead me to think that the content-type stays untouched or (at least) will not contain any charset (note the last line, where no charset is mentioned!):

/// If [body] is a `Map`, it's encoded as form fields using [encoding]. The
/// content-type of the request will be set to
/// `"application/x-www-form-urlencoded"`; this cannot be overridden.

Hence, I don't understand why this issue has not yet been fixed. The most up-to-date and also non-breaking proposal to add an optional boolean to the Request could also be applied to the unstreamed post, put etc. functions:

a new, optional bool appendCharsetIfNotSet (defaulting to true) to the Request constructor

I would happily create a PR for that as this is a huge dealbreaker for this simple http package.
Would that be okay for you or do you disagree?