POST request to a http:// which receives a HTTP 301 response redirecting to https:// is retried as GET instead

Summary.

When making a request to our API using POST to http, it responds with HTTP 301, which is considered best practice for upgrading users to https.
However, the requests library responds to this by ignoring the 'location' header and instead retries it using get, resulting in the user getting a very unexpected HTTP 405 invalid method.

## Expected Result

Either return the error 301 directly, or retry to the location specified.

## Actual Result

The HTTP 405 error from the (invalid) GET method is retured.

## Reproduction Steps

```python
from requests import Response, Session
from requests.adapters import HTTPAdapter

key = <api key from https://openindustrialdata.com>

session = Session()
adapter = HTTPAdapter()
session.mount("http://", adapter)
session.mount("https://", adapter)
res = session.request(method='POST',
                                 url='http://api.cognitedata.com/api/v1/projects/publicdata/assets/list',
                                 data='{"limit":25}',
                                  headers={'api-key':key,"content-type":"application/json"})
print(res.request.method, res.status_code)
```
The result of running this is GET 405

## Source of the error


The relevant code is in sessions.py refering to issue #1704 is:
```
        # Second, if a POST is responded to with a 301, turn it into a GET.
        # This bizarre behaviour is explained in Issue 1704.
        if response.status_code == codes.moved and method == 'POST':
            method = 'GET'
```


## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.6.1"
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.7.3"
  },
  "platform": {
    "release": "5.3.0-59-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010102f",
    "version": "19.0.0"
  },
  "requests": {
    "version": "2.23.0"
  },
  "system_ssl": {
    "version": "1010102f"
  },
  "urllib3": {
    "version": "1.24.1"
  },
  "using_pyopenssl": true
}

```





This is not a bug. All guidance around this is to not resend data or authentication (or the same method) when being redirected to a different scheme and authority. This is the correct and secure behaviour for this case.

> This is not a bug. All guidance around this is to not resend data or authentication (or the same method) when being redirected to a different scheme and authority. This is the correct and secure behaviour for this case.

Where is this supposed guidance for doing a **GET** request to a **HTTP** endpoint after being told that the POST request to a HTTP endpoint should go to HTTPS instead?

Hi @sanderland, this is standard practice for a lot of web tools and most browsers. The behavior is defined in [RFC 7231 § 6.4.2](https://tools.ietf.org/html/rfc7231#section-6.4.2).

There are a few previous issues like this one https://github.com/psf/requests/issues/3107#issuecomment-212296468 with context. Outside of a 307/308 redirect (which we respect), this is the expected behavior. If the web server MUST support this, they need to use the correct status code.

Thanks for the responses, I've raised the issue and we'll try to avoid using 301.
Nevertheless I found it hard to find out that the redirect was happening at all, a richer repr or something could make it clearer that a redirect happened.

@sanderland the quickstart has a whole section on redirection: https://requests.readthedocs.io/en/master/user/quickstart/#redirection-and-history

I'm not sure why you found it hard to find that a redirect happened, but those docs should make it clearer how to do so correctly going forward.