wtf happened to strict_mode? (POST should remain POST on redirect)

This is a followup to https://github.com/kennethreitz/requests/issues/996.

So I upgraded requests again and again my code broke. I was relying on strict_mode = True. Apparently that config functionality is gone? 

What's this "despite standards" crap, aren't y'all supposed to be better than that? I'll make a pull request if you'll use it (and once I figure out the new config mechanism).

```
            # Do what the browsers do, despite standards...
            if (resp.status_code in (codes.moved, codes.found) and
                    prepared_request.method == 'POST'):
                method = 'GET'
```


First, I'd like to remind you of the general rule for contributing to requests: [Be Cordial or Be On Your Way](http://kennethreitz.org/expressions/be-cordial-or-be-on-your-way). 

Second, you seem to have upgraded from version before 1.0. In 1.0, all configuration was removed, including `strict_mode` so there is no configuration mechanism to be figured out.

Third, requests doesn't advertise it as strictly RFC compliant and in fact, models much of its behaviours after what browsers do. In fact, far too many servers expect that from us. Unfortunately, if you'd like to replicate the behaviour that you are used to, you can do the following:

``` python

r = requests.post(url, data=data, allow_redirects=False)
while r.status_code in (requests.codes.moved, requests.codes.found):
    q = requests.post(r.headers['Location'], data=data, allow_redirects=False)
    history = [r]
    history.extend(r.history)
    q.history = tuple(history)
    r = q
```

This will properly preserve history on your request (which is ideal) and will do what you're expecting. I suppose, you could also use hooks, e.g., 

``` python
def post_redirect_hook(response, *args):
    if not (response.request.method == 'POST' and response.status_code in (requests.codes.moved, requests.codes.found)):
        return response

    # else resolve your redirect similar to above
```

Yes it is non-ideal to have to do this, but our current behaviour seems to satisfy approximately 90% (if not more) of our users.


Hi all,

Just adding a comment how I cope with this in case others stumble upon this issue.

I also needed a strict mode to mimic a client that preserves the POST method on redirects. I chose to create a StrictSession which redefines resolve_redirects for the desired behavior. That way I keep my client code the simple without resorting to hooks with another loop.

https://github.com/oohlaf/sprezz/blob/master/sprezz/util/network.py


Thanks @oohlaf!


Just adding that this bit me today. I have to talk to a server which expects me to follow the standard here. It's a little disappointing that I had to spend a non-trivial amount of time researching how to enable a standards-compliant mode in requests, then research why the solution I had found (`strict_mode = True`) didn't work, then write extra code because the solution had been removed.

While I understand wanting to remove configuration, an extra parameter in `requests.post` would not be hard for users to understand. The parameter would reduce the amount of code users have to write in order to make the requests they want, something which requests has always previously done for me.

I'm willing to write the pull request if you're willing to accept it.


BTW: The link I posted above was dead because I wanted to refactor my application, but got stalled.

The code is still there in the history at:
https://github.com/oohlaf/sprezz/blob/be9b2f7e949f3469b970053597e70c2383570375/sprezz/util/network.py


@num1: The issue is not "one extra parameter". The issue is that we get many feature requests all of which want "one extra parameter". At some point we either draw a line or end up having many thousands of parameters. 

Requests will never be perfect for all use cases. It is impossible to follow the full breadth of both _de jure_ and _de facto_ HTTP usage _and_ have a simple API. It cannot be done. 

The API is what matters to us. This means features that are only useful to a minority of developers but that add complexity to the API for all of them tend not to be accepted. At the moment, that is the case for this feature.


One extra parameter seems appropriate for something that is both rfc compliant and a feature used by at least the handful of users here. 

But okay, it's you're call, hopefully you'll reconsider or follow the spec when/if implementing the updated HTTP/1.1 RFCs (https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead). The method must not be changed for status codes 307 and 308 (http://tools.ietf.org/html/rfc7231#page-58).


@jamshid I hope next time you'll investigate the [actual behaviour](https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L134..L149) of requests. For the status codes that we [may](http://tools.ietf.org/html/rfc7231#section-6.4.2) change the method, we do because this is the unfortunate de facto behaviour that @lukasa referred to. We do **not** change them on 307 or 308 responses, ergo we already follow the new set of RFCs for HTTP/1.1.


sorry, thanks, point taken