If every http:// request gets a 301 to https://, where is the gap? In the very first request, before your redirect ever runs. That gap is exactly what HSTS closes.
Consider the sequence: a user types example.com. The browser sends a plaintext HTTP request. Your server replies 301 → HTTPS. But that first plaintext request is interceptable: an attacker on the network (the classic "sslstrip" attack, Moxie Marlinspike, 2009) can answer it themselves and keep the user on HTTP indefinitely.
HSTS (HTTP Strict Transport Security, RFC 6797) fixes this with one response header:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Once a browser sees it over a valid HTTPS connection, it remembers (for max-age seconds) to never speak HTTP to that host again — it rewrites http:// to https:// internally before sending anything. The vulnerable first request disappears.
The remaining gap is the very first visit ever, before any header is seen. That's solved by the HSTS preload list — a set baked directly into Chrome, Firefox, and Safari at build time. Submit your domain at hstspreload.org, but only with includeSubDomains and preload, because removal is slow.
Further reading: RFC 6797; the sslstrip presentation (Black Hat DC 2009).
Bottom line: a redirect protects every request except the first. HSTS plus preload closes that first-request hole.
Handshake Papers
@HandshakePapers
I redirect HTTP to HTTPS — why isn't that enough?
This post was published in the Telegram channel Handshake Papers. Subscribe here: @HandshakePapers.