Add as_http() method to print out HTTP response as a string

When a HTTP response doesn't contain the content that I expect, most times I find that the simplest debugging information I want is the actual HTTP content that was sent over the wire. Instead of having to construct all of this manually I thought it would be nice to add this information as a convenience `as_http()` request.

Example:

``` python
>>> r = requests.get('https://api.twilio.com/2010-04-01.json')
>>> print r.as_http()
HTTP/1.1 200 OK
content-length: 109
x-powered-by: AT-5000
connection: close
etag:
date: Mon, 16 Dec 2013 05:39:55 GMT
x-shenanigans: none
access-control-allow-origin: https://www.twilio.com
content-type: application/json

{"name":"2010-04-01","uri":"\/2010-04-01.json","subresource_uris":{"accounts":"\/2010-04-01\/Accounts.json"}}
```

This PR also passes through version information as an attribute on the `Response` object, and adds tests for this method.

I asked about this in IRC last week, didn't get much feedback, figured it wouldn't be too hard to just write it up and submit a PR.


Gah, tests are broken due to a Python3 encoding issue. Let me know if this is a desirable feature for the library and I'll put the work in to fix the tests.


Thanks for the pull request @kevinburke!

Unfortunately, I'm -1 on this feature. My problems with this feature are as follows:
1. It's misleading. You say in your original description that "the simplest debugging information I want is the actual HTTP content that was sent over the wire". This is almost certainly true, and is exactly what any user of this feature would expect it to give. Unfortunately, that's not what this feature provides. Instead, it provides Requests' view of the response, which is not the same thing. Mostly this is stuff that's probably trivial: all the header keys are lower case, their order isn't preserved, etc. However, the fact of the matter is that we're not showing the actual response, we're reconstructing something that matches our view of the response. This means that there's nothing in the textual output you've provided that isn't in the `Response` object already. Any unusual stuff in the HTTP response won't be shown.
   
   This gets even worse if you consider extending this to serialize HTTP requests (which is almost certainly the next step here, being infinitely more useful in debugging weird failures), since Requests cannot possibly reconstruct the HTTP request: we just don't have all the information.
2. It extends the API. We're fighting very hard to avoid extending the API if at all possible: as a result, any extension to the API automatically starts in negative territory, and must provide a very strong justification. =)

Sorry about this: thanks for doing the work, but I don't think we'll merge it. My advice to people who need this debugging functionality is either to get familiar with Wireshark or to consider using a service like [Runscope](https://www.runscope.com/).


I agree with 100% of what @Lukasa said. In fact, even curl would give you far more information to debug with. _Furthermore_, there are headers that we compute that we don't even set on the `PreparedRequest` object so adding this method to that would be useless too quite frankly. Unfortunately your best bet is something like `mitmproxy` or `wireshark` (locally) or a service like `Runscope` or `httpbin`.

With that said, the both of us are in agreement and I'm certain @kennethreitz will agree with both of us, so I'm going to close this.


Correct on both accounts :)

Very nice implementation, though!


Fair enough. FWIW, here's the code we use to implement this at Twilio:

https://gist.github.com/kevinburke/7990326

It also lets you translate from a request to curl, because this is pretty much the natural next step for us any time something breaks.


Requests used to have a "as_curl" method before 1.x but it was intentionally removed and the feature has been rejected a couple of times since though. 

Thanks for documenting that in a gist though!