There is no straightforward way to enable debug or show the raw http request + response

There's this stack overflow question: http://stackoverflow.com/q/10588644/2195033

The question is about something that should be simple: Print the whole http request.

Because often it's much easier to debug something by seeing it exactly as it was sent over the wire (Figuratively. Obviously I'd prefer the unencrypted one in the case of https)

I've visited this page way too many times. Unsurprisingly, it's always the same two answers:
- "Copypaste these 20 lines into your project to enable debugging"
- "Inspect these 20 attributes one by one, or assemble the whole thing yourself"

In the comments of the second one, someone asks 'Which of these gives me "the entire request, headers included"?'. No replies to that other than the assumption that reassembling the request manually is okay. The first one kinda does the job, but it feels like the times when i copypasted activestate recipes to be able to do multipart file uploads.

Does it really have to be this way? Why not provide built-in helpers for these things?

```
requests.enable_basic_debugging_globally()
```

Or:

```
print(req.raw_request_string_as_it_is_going_to_get_sent_over_the_wire)
print(resp.raw_response_string_with_headers_and_status_line)
print(resp.raw_response_string_with_headers_and_status_line_and_also_the_request_before_it)
```

Ok, I'm not great at api design. You get the idea.


Thanks for this!

This is a not entirely uncommon request. Unfortunately, I sincerely doubt it's going to happen. I've tackled a variant of this request before [here](https://github.com/kennethreitz/requests/pull/1802#issuecomment-30644444). The most relevant part is this:

> 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.

What's important to note is that requests is a long, _long_ way from what actually gets written in the wire. Requests builds a set of information which it passes to `urllib3`, which mutates it and passes it to `httplib`, which mutates it and passes it to the socket itself. To debug appropriately we'd need to be able to intercept that final socket write. We'd also need to be able to correlate socket writes with their appropriate request, which is hard to do because `httplib` has a non-trivial state machine in place. This represents reaching far, far into `httplib` and very far down the stack.

The problem is, all of that work is still less useful than cracking out tcpdump or Wireshark and using that to perform a packet capture. In addition to showing you the actual bytes sent and received from the perspective of the NIC driver, it can show you packet flows. This can help debug some extremely awkward problems that occasionally occur in network programming.

To sum up, I don't think there's no value in this, but I also don't think it's the right way to debug this problem. If and when we rewrite `httplib`, we can consider whether the new library can do this logging (I believe it can). Until that stage, the work required is substantial and there's an easier and better way to do it, so I doubt we'll do it.


Here I was writing a nice response and @Lukasa said it faster and better... again. ;)

Thanks for the suggestion @dequis and taking the time to file the bug. That said, you said one thing that @Lukasa didn't address and which bothered me. 

We should take the following conversation off this bug because it's entirely tangential. _Why are you copying recipes from ActiveState to do `multipart/form-data` file uploads?_ Requests provides that for you and the requests-toolbelt ensures you don't need to think about it in the case where your file is too big to be loaded into memory all at once. Feel free to email me and reply to this. 


> Why are you copying recipes from ActiveState to do multipart/form-data file uploads?

Hahah, sorry if that was unclear, I don't do that anymore. Not with requests. I was referring to the past, when urllib2 was the best thing I had.

Regarding the rest... welp.


Easy, just bundle wireshark as part of requests

## 

Kevin Burke
phone: 925.271.7005 | twentymilliseconds.com

On Thu, Oct 2, 2014 at 12:45 PM, dx notifications@github.com wrote:

> Why are you copying recipes from ActiveState to do multipart/form-data
> file uploads?
> 
> Hahah, sorry if that was unclear, I don't do that anymore. Not with
> requests. I was referring to the past, when urllib2 was the best thing I
> had.
> 
> Regarding the rest... welp.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/issues/2261#issuecomment-57694165
> .


May want to take a look at https://gist.github.com/kevinburke/7990326 which
does a lot of this and pretty prints it etc

## 

Kevin Burke
phone: 925.271.7005 | twentymilliseconds.com

On Thu, Oct 2, 2014 at 1:04 PM, Kevin Burke kev@inburke.com wrote:

> Easy, just bundle wireshark as part of requests
> 
> ## 
> 
> Kevin Burke
> phone: 925.271.7005 | twentymilliseconds.com
> 
> On Thu, Oct 2, 2014 at 12:45 PM, dx notifications@github.com wrote:
> 
> > Why are you copying recipes from ActiveState to do multipart/form-data
> > file uploads?
> > 
> > Hahah, sorry if that was unclear, I don't do that anymore. Not with
> > requests. I was referring to the past, when urllib2 was the best thing I
> > had.
> > 
> > Regarding the rest... welp.
> > 
> > —
> > Reply to this email directly or view it on GitHub
> > https://github.com/kennethreitz/requests/issues/2261#issuecomment-57694165
> > .