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