When Flurl.Http gets a non-successful response, it does an await ReadAsStringAsync on the content before throwing, whether you need it or not, so it can pass the response body along in the FlurlHttpException. The reason it does this ahead of time was convenience - typically you needed to access the error body from a catch block, and at the time C# did not support awaiting in a catch block. That changed with C# 6, which was released in mid-2015. I believe enough time has now passed that we can do away with this inefficiency and and require awaiting those if/when you actually need them.
Breaking changes:
FlurlHttpException.GetResponseString will be replaced by FlurlHttpException.GetResponseStringAsync.FlurlHttpException.GetResponseJson will be replaced by FlurlHttpException.GetResponseJsonAsync.HttpCall.ErrorResponseBody will be removed entirely.These changes are tentative at this point, chime in below if you have concerns.
For breaking changes you should increment major version - see https://semver.org/.
Developers do not expect breaking changes when they update package with minor version increment.
Most helpful comment
For breaking changes you should increment major version - see https://semver.org/.
Developers do not expect breaking changes when they update package with minor version increment.