Requests ignores HSTS if redirected to http:// version of site

Requests will follow an unencrypted http:// redirect from a site that implements HSTS.

## Expected Result

I expected Requests to force https:// handling of all http:// URLs for a site which has advertised Strict-Transport-Security.

## Actual Result

Requests followed a 301 redirect to Location: http://site and, since port 80 was blocked for that site, spun forever and timed out.  

(Note, the fact that an HSTS site is redirecting to a closed and unencrypted port is a sin on the site's behalf, not being defended here, but it illustrates the HSTS handling very nicely.  Requests times out because it tries to follow the http:// link.  Chrome, Firefox, Edge, and Internet Explorer all ignore the http:// referral and rewrite it as https://, arriving at the target landing page.  Chrome developer mode describes it as a "307 Internal Redirect" and "Non-Authoritative-Reason: HSTS").

## Reproduction Steps

```python
import requests
r = requests.get('https://olb.bsf.net', timeout=(3,15))

```
Site sends a 302 Redirect to /login, then a 301 Redirect to http://olb.bsf.net/login/.  This last redirect to an unencrypted URL is what exposes the behavior.  Since the site doesn't listen on port 80, this request will time out and throw an urllib3.exceptions.MaxRetryError error.

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.9"
  },
  "platform": {
    "release": "5.7.6-x86_64-linode136",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1010100f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}

```



See also https://github.com/psf/requests/issues/3872 - this isn't supported by Requests (unfortunately) and the corresponding work in urllib3 never landed

@gowenfawr can you please confirm that the redirect stucks on the _second_ redirect (which explicitly mentions http:// )? 
I noticed a probably similar (or at least connecting) issue, I made a GET request against https://my-site/delete-confirm/ which replied with 302 and location=/delete-success in headers and then I got a 
ConnectionError: HTTPConnectionPool(host='my-site', **port:80**) max retries exceeded with url: /delete-success.
My expectation (based on https://tools.ietf.org/html/rfc3986#section-5) is that since the first request is made against https://, the second one should do the same but apparently it uses http://. 

@visko-sc can you share how you're confirming this? I wonder if you could try using a session (`s`) and sending the original request with `allow_redirects=False` and then call `next(s.resolve_redirects(resp, resp.request, yield_requests=True))` and inspect the `.url` attribute to verify your theory. If the location is `/delete-success` you're correct that it should be using `https://`. (That's what https://github.com/psf/requests/blob/143150233162d609330941ec2aacde5ed4caa510/requests/sessions.py#L188 does)

@sigmavirus24 with the session, the resolved redirect shows correct value:
`prepped = next(s.resolve_redirects(resp, resp.request, yield_requests=True))` and 
`prepped.url == https://my-site/delete-success`.
However, when I do `session.send(prepped, timeout=10)`, I get
`{ConnectTimeout}HTTPConnectionPool(host='my-site', port=80): Max retries exceeded with url: /delete-success/ (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f397cf097f0>, 'Connection to my-site timed out. (connect timeout=10)'))`

Previously what I have done:
- `requests.get('https://my-site/delete-confirm')` raised the same exception as above and 
- `requests.get('https://my-site/delete-confirm', allow_redirects=False)` returned with a Response object where
`response.headers['location'] == '/delete-success'`

So can you alter `session.send(prepped, timeout=10)` to `session.send(prepped, timeout=10, allow_redirects=False)` and see if you get another redirect and where that one sends you?

(To be clear, I have a suspicion your server is redirecting you to `http://` eventually expecting HSTS to kick in but we don't support HSTS so we're doing what the server has told us to do.)

Also, do you actually get a `strict-transport-secuity` header at any point?

Oh, you are right, 302 is followed by 301, this time pointing to `http://my-site/delete-success`. I do get the `strict-transport-security`, but I understand that this is not supported yet. Thanks for your time and pointing out this issue.

@visko-sc no worries. My hope is that our conversation debugging this helps others understand how to debug it as well. I have ideas on how HSTS might be supported, but no time to implement them