Allow access to original requests request

[jamielennox]

It would have been nice to allow access to original requests request so one could inspect that correct information was provided

Launchpad Details: #LP1564205 kolya - 2016-03-31 03:11:31 +0000

[jamielennox]

This patch adds ability to access original requests request for inspection.

I would have submitted it via gerrit but registration process is overly complicated.

I hope you'll find this useful. Thanks!

Launchpad Details: #LPC kolya - 2016-03-31 03:16:00 +0000

[jamielennox]

Sorry the gerrit is so difficult, i thought it was just a launchpad sign in then add a public key but it has been a while since i've done it. I've uploaded it here https://review.openstack.org/#/c/300190 as it will need to go via that process anyway for tests.

I like the addition of timeout and allow_redirects to the RequestProxy i might split that off, add a test or two and merge it seperately if you don't mind?

With the requests' request object, i'm pretty sure i see what you're doing but i just want to understand the use case a little more. For most people using the get() or request() functions they'll never notice the difference between a Request and a PreparedRequest, and you can access all the properties of the PreparedRequest via the RequestProxy. So when you say "the correct information was provided" i'm not sure what you are looking to validate that will not come through to the PreparedRequest?

The only thing i can think is maybe you are subclassing requests.Request and there is something you want from it in the test? I'm just trying to imagine what that information would be that is not present in the PreparedRequest.

Launchpad Details: #LPC Jamie Lennox - 2016-03-31 23:15:42 +0000

[jamielennox]

The easy half, i'll wait for your ack before commiting: https://review.openstack.org/#/c/300254/

Launchpad Details: #LPC Jamie Lennox - 2016-04-01 00:07:01 +0000

[jamielennox]

This is an example we use requests_request for: self.assertEquals(history[0].requests_request.files, {'0': '123', '1': '456'}) self.assertEquals(history[0].requests_request.headers, {'Host': 'example.com'})

Launchpad Details: #LPC kolya - 2016-04-01 02:14:23 +0000

[jamielennox]

To be honest, I would have preferred to have full access to Request instead of PreparedRequest. From unit testing perspective I do not really care what requests does internally - I just would like to make sure my code gives it right things - from this perspective PreparedRequest seems to be too much of implementation detail.

Launchpad Details: #LPC kolya - 2016-04-01 02:20:58 +0000

[jamielennox]

Well in 90%+ of cases the user doesn't know about the Request object either - but that one is better documented. Having said that when you do a response.request you get a PreparedRequest so it is a known stable interface.

So it feels more like you want to mock the calls to the library rather than what is going over the wire. To ensure parameters are passed i think it is beneficial to just go ahead and use the mock library. I'll need to think about this but my initial response is that i would like to be closer to the network level and test what is actually being sent. I trust requests but my servers are seeing the full request and so i want to test the full request.

Files is an interesting one and i'd be open to seeing if there is a better way to handle this - i haven't really used the library for that purpose. Again though, i think I'm more interested in seeing the contents of the file and what is sent over the network as part of the request than caring whether you pass the data to requests as a string, file handle or other.

Taking your second example, comparing headers, the issue (for better or worse) of doing an exact compare like that on the original request is that you don't take account of Content-Type, Content-Length, User-Agent and a bunch of other headers that are set. Particularly for this example you can already do:

self.assertEquals('example.com', history[0].headers['Host'])

I'm torn between this is a fairly small addition that will help someone out, and I don't see anything yet that you need that isn't already available though perhaps in a different format. Can we solve it by better documentation on the RequestProxy object and what is available there? The documentation can be difficult as there are private classes with public interfaces.

Launchpad Details: #LPC Jamie Lennox - 2016-04-01 05:27:40 +0000

[jamielennox]

Well... yes, I guess headers would work - I might have missed documentation for those.

But as far as I can see there is no way to get files out of prepared request because by that time they are all converted into one unpredictable string. So what should be the strategy there?

Launchpad Details: #LPC kolya - 2016-04-01 13:06:14 +0000

[joaompfe]

I also would like to access the Request object instead of the PreparedRequest in the callback. In my case, I want to validate the files attribute, which is not available in the PreparedRequest.

In fact, the documentation is misleading when says that request is of type Request, as its type is PreparedRequest.

[boukeas]

I also would like to access the Request object instead of the PreparedRequest in the callback. In my case, I want to validate the files attribute, which is not available in the PreparedRequest.

I have the exact same use case, i.e. validating the files posted in a request. Is there any way to do that?