1

I'm attempting to use requests to POST form-data and need to check the status code of the POST request itself, however despite specifying allow_redirects=False, the request is still redirecting to a GET request, which returns a status code of 200, rather than the POST's status code of 302.

Note: I have tested the exact same POST request in Postman with automatic redirects turned off and am getting expected behaviour.

Edit:

I was able to find a property called strict_mode on Requests' PyPi page here

I managed to find this on the french requests docs by using an absolute search for strict_mode on Google, however the same place on the English docs doesn't list the property.

Here's an excerpt from the French docs that pertains to my question:

strict_mode: If true, Requests will do its best to follow RFCs (e.g. POST redirects).

Edit 2:

I've found this regarding strict_mode on the requests github repo: https://github.com/psf/requests/commit/95a03532c36f1afd38c395f7160c7f7086557b7b

It appears to have been removed since 2012 so, is there a way to bypass this that isn't hacky?

Originally posted this as an answer before finding that it didn't work:

It appears that I'll have to do something similar to this: https://github.com/psf/requests/issues/1325

I found this on google: https://subscription.packtpub.com/book/networking_and_servers/9781784395414/1/ch01lvl1sec18/tracking-redirection-of-the-request-using-request-history

For anyone else with this issue it shows how to get a list of previous statuses when being redirected

Edit:

Just tried implementing this, history is blank even with allow redirects set to true. I'm not sure how Postman can get the 302 code, Chrome dev tools can get the correct code when viewing the network tab, but requests can't.

100pxsquared
  • 53
  • 1
  • 10
  • a) requests is open source, so you can see what strict_mode might do, and b) surely the first place to search and then perhaps ask about a requests problem like this is on the requests github Issues? – DisappointedByUnaccountableMod Jun 03 '20 at 16:15
  • @barny Regarding your first point, I'll do that now. Regarding your second, the last thing that I assume is that it is a fault with the library, rather than me making a mistake or misunderstanding something, and judging by the complete lack of information regarding POST redirects online is evident of it not being a bug. – 100pxsquared Jun 03 '20 at 16:18
  • There's not a 'complete lack of information regarding POST redirects'. It's there in the github issues; see https://github.com/psf/requests/issues/5284 - suggest you post some [mre] code and a URL it shows the problem against. – DisappointedByUnaccountableMod Jun 03 '20 at 16:35
  • Also see https://github.com/psf/requests/issues/5003 for someone having problems with POST on a site that *really* doesn't want non-humans to access it. – DisappointedByUnaccountableMod Jun 03 '20 at 16:38
  • @barny The final comment on that issue is that you should be able to pass `allow_redirects=False` "to disable auto redirects", however this doesn't seem to be the case. Clarification: issue 5284 – 100pxsquared Jun 03 '20 at 16:41
  • Yes and note I didn't say that wasn't the case - and that's why if you want help you should edit some working minimal code into your question - I should be able to paste it into a file and run it _without adding anything_ - and a URL that shows the problem you are seeing. – DisappointedByUnaccountableMod Jun 03 '20 at 16:45
  • @barny I can't exactly show my u/n and p/w on a public website can I? – 100pxsquared Jun 03 '20 at 16:54

1 Answers1

0

Thanks to a comment in a Stack Overflow link inside the GitHub issue posted by @barny in the comments on my question, I enabled http debugging and saw that I was using an old url because I had forgotten to update the variable containing the url from a test one to the correct one I was using in Postman.

So despite the code technically working, it wasn't POSTing to the new url.

100pxsquared
  • 53
  • 1
  • 10