POST with redirection becomes GET

## Expected Result

HTTP 301 redirection of a POST request should either send a POST to the new target URL, or return the HTTP 301 without redirecting at all.

## Actual Result

It's redirecting to the new `Location`, but replacing the method by GET.

## Reproduction Steps

```python
import requests
resp = requests.post("http://amp.labs.scielo.org/w2v1/xml")
resp.request.method  # It's a GET
resps = requests.post("https://amp.labs.scielo.org/w2v1/xml")
resps.request.method  # It's a POST
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.8"
  },
  "idna": {
    "version": "2.8"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.8.0"
  },
  "platform": {
    "release": "5.4.1-arch1-1",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "1010104f",
    "version": "19.1.0"
  },
  "requests": {
    "version": "2.22.0"
  },
  "system_ssl": {
    "version": "1010104f"
  },
  "urllib3": {
    "version": "1.25.7"
  },
  "using_pyopenssl": true
}
```

This is expected behavior. Blame browser implementations of 301 redirects: https://tools.ietf.org/html/rfc7231#section-6.4.2

The status code to perform a permanent redirect without changing POST to GET is 308.

RFC7231 tells that the client *MAY* change the method, I think that's not a strict requirement (so a generic client should be able to keep the method as well), and the server should also handle the redirected request keeping the original method (i.e., even with the RFC and the history of browser implementations, I see no reason to replace the method by a GET). When the redirection results in an HTTP 405, it's clear that the server doesn't expect a redirection to a GET, but I don't know if most servers are aware of that (my guess is that they're not, but that's just a guess anyway).

I don't think that using a GET on a 301 redirection should be the default behavior, but shouldn't `requests` at least have a keyword argument to control that (something like `use_get_on_301`)?

Well this client does change the method so is compliant. If you're looking for an override you can subclass a `Session` and provide your own [`prepare_method()`](https://github.com/psf/requests/blob/67a7b2e8336951d527e223429672354989384197/requests/sessions.py#L313) function which simply returns the old `request.method`.

Shouldn't it be the other way around? I mean, shouldn't keeping the original request method be "simpler" than replacing it by a GET on redirections? Anyway, creating a class and using inheritance just to behave like another RFC7231-compliant client might mean that something is missing.

I'm asking that because I'm not aware of any use case where that replacement is desirable.

Since RFC specs is ambiguous (_MAY_) regarding 301 redirection and POST requests, IMO this behavious could be guided with a boolean flag provided to `Session` constructor.

Hello, I want to contribute to requests. But I have not contributed in this repo before and I am having trouble in understanding code of requests library. I just want to ask How much knowledge of computer networks is required in understanding codebase ? and what libraries should I learn before understanding to requests are there any other prerequisites? Thanks in advance

@sevdog, @danilobellini , @sethmlarson , @nakajima can you please help regarding the above?

Seth's suggestion is right here. If you need to handle redirect explicitly, you can either subclass the redirect mixin, or use the `allow_redirects` flag to disable auto redirects. At that point, you can handle the workflow in whatever way you'd like.

Redirecting a POST->GET on 301,302,303 redirects is common in most http implementations. You'll find your browser does it as well as other tools that support automatic redirects. This behavior is intentional to prevent sending payloads or other sensitive info to unexpected servers. Once you've been redirected, you can then choose to resend your post to the new endpoint if it's still the desired destination.