Expand RequestMethods optional arguments

I’ve come across at least one example of an API where I need to both POST a body of some form and also have query parameters on a request, and this is something I’m accommodated so far in my beekeeper project - largely because I’ve been handling setting those items up in my own code.

I’m now migrating that to urllib3, and one snag I’m seeing is that RequestMethods.request() takes a single fields argument that turns into either a querystring or x-www-urlencoded depending on method- as far as I can tell, there’s no way to choose to pass either one or the other explicitly.

Would there be any objection to expanding the request() signature to enable those items to be passed explicitly? The way I’m conceiving of it, fields would still be encoded according to the request method, while the type-specific arguments (params and form? Dunno - suggestions welcome) would always be added to the request in their specified format.

If this isn’t an appropriate extension, it’s not a big deal - I can keep doing it in my own code.

[haikuginger]

New structure should be much easier to test for stuff like this; I’m having .request() request modified headers/URL/body from a couple encoding methods rather than having those methods inline with the HTTP pipeline.

I’ll also submit a patch and PR for that separately so it’s fixed in the meantime.

[shazow]

Huh right you are, that looks like a bug, and we need a test! 😄