Map ports and understand the first-visit boundary
05HSTS changes how the browser prepares an HTTP load. It does not make a server speak TLS, repair a certificate, protect every other protocol or guarantee a safe first visit to a previously unknown host.
Alternative first visit: the browser already has an applicable preconfigured policy. It rewrites the HTTP link before any outgoing request and attempts HTTPS. This mitigates this bootstrap gap; it does not guarantee the site, device or content is trustworthy.
Source for this drawing: RFC 6797 · Read RFC section 8.3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A remembered or preconfigured policy upgrades before the network; an unknown host may still have a bootstrap gap.
- For an applicable HTTP URL, an explicit port 80 MUST become 443. A different explicit port MUST be preserved. If the URL has no explicit port, the browser MUST NOT add one. Paths and queries are not rewritten by this port rule.
- HSTS applies to HTTP over all ports on the known host. http://example.com:8080/ becomes https://example.com:8080/, not port443. If that port serves only plain HTTP, the secure connection fails; there is no HSTS-authorized HTTP fallback.
- Without already learned, user-configured or preloaded HSTS, a first plain HTTP visit can be intercepted. A server SHOULD send a permanent HTTPS redirect, but that first insecure exchange remains exposed (§7.2 and §14.6). This is not a claim that every current browser always starts insecurely.
- A browser vendor’s preconfigured HSTS list can mitigate that bootstrap gap (§12.3, non-normative advice). This RFC does not define enrollment requirements or make a "preload" header token enroll a site automatically.
- HSTS is not a general anti-phishing or malware defense, does not replace appropriate certificate and application security checks, and does not by itself specify all mixed-content behavior. Its whole-host scope also differs from the scheme/host/port same-origin policy.
The guide uses contemporary HTTPS/TLS terminology rather than recommending the old SSL references in the immutable 2012 text. No preload submission, site configuration change, cookie attack, certificate bypass or real network request is performed by the teaching model.
Read the RFC section ↗