Feature Suggestion: Include response body in raise_for_status method

#4233 

Potential implementation of my feature suggestion

> The response object is already attached to the exception, which means it's fairly trivial for user code to access this data in a way that is going to be safe for their application. What benefit do we obtain by placing the body into the exception message, and does it outweigh the risks?

This is exactly my question. And in all fairness, I'm fairly certain the benefit is "nothing". This will also only hurt folks who already depend on our current _decently_ formatted messages when logging response errors (i.e., so many command-line clients that would break).

I'm pretty sure what's actually happening here is that our documentation is not sufficiently clear enough to indicate that the response is attached to the exception.

I'm pretty strongly convinced this is a bad idea.

As for the merits let me give you a pretty clear example:
Imagine you are wrapping an existing API because its interface is terrible or has secret keys you don't want to expose client side. The existing API gives back reasonable error information in the body when an 'illegal' value is passed but has no way to know what values it will accept for certain query parameters.
So currently requests raises an error message like this 
```
HTTPError: 400 Client Error: Bad Request for url: https://PROTECTED_TO_HIDE_SECRETS
```
Which frankly isn't enough information to pass along for troubleshooting while trying to stay true to wrapping the existing API and not adding a lot of boiler plate error handling that is ALREADY in requests "raise_for_status" method.
However like said above the wrapped API has a reasonable error message 
```
{"faultCode":"DIAGNOSTIC CODE","responseCode":"400","message":"This release is not available or does not cover the requested index."}
```
As in the original feature suggestion issue: wouldn't it be nice to see that without needing more boilerplate error handling?

And attaching the response to the exception still means I need boilerplate just to get that message.

To the statement of it breaking existing folks, sure I can buy that, so we can use an keyword in invocation of the function to select whether or not to include that text.

> As in the original feature suggestion issue: wouldn't it be nice to see that without needing more boilerplate error handling?

Sure, but maybe your API returns the message in headers. Or maybe it's a very large JSON document where only one part is relevant. Or maybe it's like [GitHub's 404 page](https://github.com/dddd/dddd), a 126kB HTML document that would all of a sudden turn this exception text:

```
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://github.com/dddd/dddd
```

Into

```
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://github.com/dddd/dddd Response Body: <!DOCTYPE html>\n<html>\n  <head>\n    <meta http-equiv="Content-type" content="text/html; charset=utf-8">\n    <meta http-equiv="Content-Security-Policy" content="default-src \'none\'; base-uri \'self\'; connect-src \'self\'; form-action \'self\'; img-src data:; script-src \'self\'; style-src \'unsafe-inline\'">\n    <meta content="origin" name="referrer">\n    <title>Page not found &middot; GitHub</title>\n    <style type="text/css" media="screen">\n      body {\n        background-color: #f1f1f1;\n        margin: 
```

I contend that this is very much not an improvement, especially as it'd have to be rendered in 80-character wide terminals and so would end up taking multiple lines.

The general problem of this approach is that while in *some* situations it works nicely, in many others it works very badly. The negative experience from the bad cases vastly outweighs the convenience in the good cases, IMO, so that suggests that you should probably tolerate the two lines of boilerplate required to get the exception message you'd actually like to see.

@Lukasa ... Well considering that the use case I am looking at has nothing to do with terminals then sure but rather browsers themselves. As I let the error bubble back up to the client browser. 

And in response to your earlier piece. I made the behavior optional and limited so who it would "work really badly" for is somewhat elusive.

And not to be a jerk but I think the whole 80 character thing really shows a disconnect with reality. I honestly don't know a single developer who uses the 80 character terminal width on a regular basis. So IMO this whole line of reasoning is totally bunk.

Lastly, if the tagline is really about HTTP for Humans. Then you tell me what is more actionable: "400 Client Error" or "400 Client Error: ERROR TEXT". The 404 case is silly here because 404 has a specific meaning. 400 is a general 'caller screwed up' message.

Alright climbing off that soapbox. If you don't want it totes cool with me. Good day!

Sorry to rip this one open again, but I actually want this behavior. Or at least, I don't want to duplicate what's in raise_for_status just to add the body.. It would be nice to have `raise_for_status(include_body=True)` or `raise_for_status('additional message')`

Would either of these satisfy both set of requirements? 

No. `raise_for_status` is meant to help with control flow, not give you a complete response body when you already have the response. Further more, if you aren't handling it and some third party is (e.g., Rollbar, Sentry, etc.) you could leak sensitive information to that service which is more than likely not what 99% of our users want. Secure by default means secure in every aspect, including trying as hard as possible to prevent people from shooting themselves in the foot with our defaults.

It wouldn't be a default. Let users ask to include the body if they want it, but don't make it a default.