fix: improve fallback to null on empty responses

[knaeckeKami]

fixes #2279

This improves handling of the following case:

• ResponseType is json
• Server Content-Type is json
• Server Content-Length is nonzero
• Response Body is empty

This can happen in some cases according to HTTP spec (e.g. HEAD requests), but some servers return responses like this (see #2279) also in other cases, even if it violates the HTTP spec.

With #2250, in some of these cases dio would throw an exception, which caused a regression for some users; see #2279 I do believe that dio should handle these cases for gracefully,

This PR brings back the previous behavior of returning null.

New Pull Request Checklist

• [x] I have read the Documentation
• [x] I have searched for a similar pull request in the project and found none
• [x] I have updated this branch with the latest main branch to avoid conflicts (via merge from master or rebase)
• [x] I have added the required tests to prove the fix/feature I'm adding
• [x] I have updated the documentation (if necessary)
• [x] I have run the tests without failures
• [x] I have updated the CHANGELOG.md in the corresponding package

Additional context and info (if any)

[Schwusch]

This is also a problem downstream in package:retrofit, where/when content type is always JSON but response body is empty. Is there someone that can approve this? @ueman ?

[ueman]

@kuhnroyal @AlexV525 Do we want to release this as 5.7.0 or as a 6.0.0? This could be considered a breaking change, but it doesn't really feel like a big change. What do you think?

[knaeckeKami]

I'd argue it's a bug fix, as the change occurred with #2250, and this restores the old behavior.

But of course, a bug fix can also be viewed as a breaking change if people depend on it ;)

[ueman]

I'd argue it's a bug fix, as the change occurred with #2250, and this restores the old behavior.

But of course, a bug fix can also be viewed as a breaking change if people depend on it ;)

Yeah, I'm tempted to release it as 5.7.0, but I still would like to hear their opinion

[knaeckeKami]

I added a test here: https://github.com/cfug/dio/pull/2285/files#diff-60c4759d76b4a7475d5c699664cbe409ca3cf5c6f09a403a5f3d2a4c4dd08ed6R330

This test would pass before #2250, and after this PR is merged. With the current release, it would fail.

A user opened #2279 because of that.

The server sends an invalid response (according to the HTTP spec), but I still think that it's better to handle such cases gracefully in an HTTP client (especially if the old behavior was graceful (return null instead of throwing an exception).

[github-actions[bot]]

Code Coverage Report: Only Changed Files listed

Package	Base Coverage	New Coverage	Difference
dio/lib/src/transformers/fused_transformer.dart	🟢 91.3%	🟢 93.33%	🟢 2.03%
dio/lib/src/transformers/util/transform_empty_to_null.dart	🔴 0%	🟢 87.5%	🟢 87.5%
Overall Coverage	🟢 84.39%	🟢 84.46%	🟢 0.07%

Minimum allowed coverage is 0%, this run produced 84.46%