Requests loses payload when encountering HTTP code 301

<!-- Summary. -->

When connecting to an endpoint with HTTP that has HTTP -> HTTPS redirect enabled, Requests loses the payload and sends no payload when reconnecting to the endpoint with HTTPS. It is considered good practice to redirect non-HTTPS traffic to HTTPS. The widely-accepted method is to set up a web server to send an HTTP 301 error ("Moved Permanently") back to the client with the equivalent HTTPS URL, and clients are expected to reconnect to the given HTTPS URL. When the requests library encounters this, it connects to the HTTPS URL, but does not re-send the payload. 

<!-- What you expected. -->

Since the end user expects a 301 redirect to be transparent, Requests should re-send the payload to the new HTTPS endpoint URL.

<!-- What happened instead. -->

Requests sends no payload, the expected result is not seen from the API, and [I come to GitHub searching for help and coldly get told I didn't RTFM and I get my issue closed immediately before more empathic users have a chance to help me look into it.](https://github.com/psf/requests/issues/6308#issuecomment-1352419014)

```
#!/usr/local/bin/python3

import requests

id = 1000
api_url_root = "http://[api url]"
api_access_token = "[access token]"

api_url = api_url_root + "/items/filmstrips/" + str(id) + "?access_token=" + api_access_token

payload={'problem': False}

response = requests.patch(api_url, json=payload, headers = {'Content-type': 'application/json'})

```

By [enabling logging as outlined in this StackOverflow post](https://stackoverflow.com/questions/10588644/how-can-i-see-the-entire-http-request-thats-being-sent-by-my-python-application), I can see the data Requests is sending to my API. in this data we can see that the payload is not re-sent when Requests re-connects to the endpoint with HTTPS:

```
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): [redacted]:80
send: b'PATCH /items/filmstrips/1000?access_token=[access token] HTTP/1.1\r\nHost: [api url]\r\nUser-Agent: python-requests/2.28.1\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nContent-type: application/json\r\nContent-Length: 18\r\n\r\n'
send: b'{"problem": false}'
reply: 'HTTP/1.1 301 Moved Permanently\r\n'
header: Date: Thu, 15 Dec 2022 15:42:05 GMT
header: Server: Apache/2.4.41 (Ubuntu)
header: Location: https://[api url]/items/filmstrips/1000?access_token=[redacted]
header: Content-Length: 396
header: Keep-Alive: timeout=5, max=100
header: Connection: Keep-Alive
header: Content-Type: text/html; charset=iso-8859-1
DEBUG:urllib3.connectionpool:http://[api url]:80 "PATCH /items/filmstrips/1000?access_token=[access token] HTTP/1.1" 301 396
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): db.uncommonephemera.org:443
send: b'PATCH /items/filmstrips/1000?access_token=[access token] HTTP/1.1\r\nHost: [api url]\r\nContent-Length: 0\r\nUser-Agent: python-requests/2.28.1\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Thu, 15 Dec 2022 15:42:05 GMT
header: Server: Apache/2.4.41 (Ubuntu)
header: Content-Security-Policy: script-src 'self' 'unsafe-eval';worker-src 'self' blob:;child-src 'self' blob:;img-src 'self' data: blob: https://cdn.directus.io;media-src 'self' https://cdn.directus.io;connect-src 'self' https://*;default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';object-src 'none';script-src-attr 'none';style-src 'self' https: 'unsafe-inline'
header: X-Powered-By: Directus
header: Vary: Origin,Cache-Control
header: Access-Control-Allow-Credentials: true
header: Access-Control-Expose-Headers: Content-Range
header: Cache-Control: no-cache
header: Content-Type: application/json; charset=utf-8
header: Content-Length: 1155
header: ETag: W/"483-sGHR5YbuBGXNuxYH9U0ytfDhitE"
header: Keep-Alive: timeout=5, max=100
header: Connection: Keep-Alive
DEBUG:urllib3.connectionpool:https://[api url]:443 "PATCH /items/filmstrips/1000?access_token=[access token] HTTP/1.1" 200 1155
```

If I change `http://` in the API URL to `https://`, there is no redirect, the payload is not lost, and the payload is sent to the API.

In my case, the use of `http://` over `https://` was inadvertent, and if I had not done this Requests would have worked as expected. However, this bug plus the reactionary response from Requests devs that I must be too stupid to use their library cost me almost a full day's worth of time. It is hoped that by publishing this issue, I can help others in my situation avoid dealing with people who do not want to help.

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "2.1.1"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.4"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.10.8"
  },
  "platform": {
    "release": "21.6.0",
    "system": "Darwin"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.1"
  },
  "system_ssl": {
    "version": "1010113f"
  },
  "urllib3": {
    "version": "1.26.12"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}
```

<!-- This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c). -->


This is a known behavior and consistent with RFCs for HTTP, please search closed issues before opening a new one.

Typical.

I don't need to "search for closed issues" once I figured out what was happening, you either fix it or you don't. I can use https for the endpoint, it was inadvertent. I was hoping maybe it would help someone else who might come here and have their issue rudely closed seconds after typing it all out.

What _would_ have been helpful is when I posted my issue originally yesterday, your admin friend said "you're not by any chance running into this HTTP 301 behavior? Here's a link to the issue, we're not planning to fix it." That would have been the right thing to do. 

You all need to stop replying "RTFM" and maybe do more LTFC: Learn to fucking communicate.