Providing content encoding for UnexpectedResponse errors.

[mitrydoug]

Summary

Is there a reason why UnexpectedStatus holds response content as bytes rather than str? I ask because (in principle) UnexpectedStatus.content can't be decoded without the encoding, which is provided by the response.

If this concern is valid, what change would be warranted? I imagine changing the UnexpectedStatus.content field is a breaking change. Could we add another field, UnexpectedStatus.text: str?

[dbanty]

An arbitrary response is not guaranteed to contain text in the body, so calling .text on it may result in an exception when attempting to decode with... whatever encoding is set (defaults to utf-8). It's also possible that the body does contain text, but the charset was not set in the Content-Type response header, in which case the default of utf-8 is assumed, which again, could be wrong.

So really, without prior knowledge of what the response from the API is going to be, you can't know how to or if you can decode into text.

I think the "real" answer to this is to expose the httpx Response object directly so that people can do whatever more advanced things they want. I've been waiting for httpx 1.0 to expose more of it through the generated clients. They're still inching along toward that goal 😅.