Ability to dump request content

There is no way to dump request content.  Currently digging with tcpdump and wireshark shows that the requests should be going through fine; r.history shows 302 and 401 for a digest authorization, and r.status_code gives 200.

Running curl with the data I'm giving is making the target Web application (a closed-source Java app) take state-altering actions.  Running with Python requests is doing absolutely nothing.

The main problem here is I have absolutely no way to debug why this is happening.


If you're digging with Wireshark, you are seeing exactly what went out on the wire. Requests cannot give you better information than that.

As it turns out, you can get very close to the information you want by examining the `PreparedRequest` that was created. For instance, the request that triggered the 200 is stored on the response as `response.request`. The others can be found on the response objects in the history.

As to your actual problem, if Requests is getting a 200 back then the server is totally OK with what Requests is doing. If I were you I would compare the HTTP sent out by Requests and that sent out by curl and see what the differences are.


Ah okay.  The documentation for this is VERY poor and doesn't mention this.  It seems like the API docs on the Web site are in the form of "Oh, you can do X, see?" rather than "You have this object, it has these methods, they perform these functions."  I'm finding all kinds of undocumented stuff in the code.

You would be surprised how poor a tool abstracted 3 steps is from a tool doing actual work.  Juggling data out of wireshark tells me what happened, but it doesn't tell me why I got a 200--I get a 200 from python r.status_code, but there is no 200 shown in Wireshark.

I've used things like Web Scarab in the past to get a better view step-by-step of what's going on, which allows for slowing down and examining the time dynamic.  Likewise it's nice to see what the program thinks it's doing versus what's actually happening--tcpdump and wireshark are showing me that the program has strange ideas of what's going on.


As to your documentation issue, it looks like you want [this](http://docs.python-requests.org/en/latest/api/). Admittedly some of this is incomplete (and the `Response.request` property is missing), so we'd be happy to accept PRs that improve it.

Returning to the bug, I'm gobsmacked that Requests thinks it's getting a 200 if there isn't one on the wire. Requests is also abstracted: much of the crafting of HTTP is done in urllib3, which is itself built on httplib. In fact, Requests gets the status code from the response object returned by urllib3, which gets it from httplib. There is no logic in Requests to change the status code _except_ to fall back to `None` if no status code is provided.

Is it possible for you to send me a pcap file showing the traffic on the wire? Obviously you can say no if there's any sensitive information or information you don't want me to see in there, but I'm interested to see what HTTP message Requests is misinterpreting.


I should open a different bug for that, but yes I'll send you some stuff, we can talk offline.  I don't see anything critical in here (scrubbed, digest auth) but rather not plaster this around the net anyway.


@bluefoxicy @Lukasa is this still an open issue? It looks like its being resolved for the opener offline.


My particular issue was a bug in my code.  This still sends GET requests.
Looks like I missed the documentation for this, so maybe a documentation
issue but this report is otherwise invalid.
On Feb 27, 2013 1:41 PM, "Philip James" notifications@github.com wrote:

> @bluefoxicy https://github.com/bluefoxicy @Lukasahttps://github.com/Lukasais this still an open issue? It looks like its being resolved for the
> opener offline.
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/1211#issuecomment-14191018
> .


@phildini, @bluefoxicy is simply providing sensitive information to @Lukasa so that he can get a better idea of what is happening in his specific case. The issue of dumping content is a moot one, IMO, but do-able as @Lukasa suggested. This feature has been requested several times before (unsuccessfully obviously) and combining its track record with our feature freeze, it likely won't be added to requests.

It could be done in the form of a response hook (beyond what @Lukasa mentioned), e.g.,

``` python
def dump_request(response):
    logger.debug(response.request.url)
    logger.debug(response.request.body)
    # etc.

r = requests.request(method, url, #etc.
                     hooks={'response': dump_request},
                     )
```

Also since @bluefoxicy has claimed this to be invalid on his own accord, I'm closing this issue.