Domains, CDN & Web Delivery

HTTPS Redirect

Definition

An HTTPS redirect is a server response, not a page. A visitor who types a bare hostname, follows an old link or clicks a printed address usually arrives on port 80 without the protocol prefix; the server answers with a 301 redirect whose Location header carries the identical path under https://, and the browser fetches that instead. The redirect should preserve the path and query string exactly — sending every insecure request to the home page instead is a common and damaging shortcut. It pairs with the Strict-Transport-Security header, which tells the browser to skip the insecure request on future visits for a stated period, commonly 31536000 seconds. The redirect handles first contact; the header removes the need for it afterwards.

Why It Matters

Two addresses serving the same content is a duplication problem before it is a security one. Search engines may index both, splitting links and ranking signals between them, and analytics reports the same page twice under different origins. The security gap is real but narrow: the very first insecure request still goes out in the clear, so anything on the path can see which page was wanted and, in principle, answer before the real server does — which is the hole Strict-Transport-Security closes. There is a visible cost to getting it wrong too, because a chain that runs from insecure bare domain to insecure www to secure www adds two round trips, roughly 200 milliseconds on a mobile connection, before a single byte of the page arrives.

How It Works

A request to port 80 is matched and answered with status 301 and a Location header holding the same host and path under https://, and the browser repeats the request there. Use 301 rather than 302: a permanent redirect is cached by browsers and understood by search engines as consolidation, while a temporary one is refetched and passes no such signal. Once the secure version is proven, add Strict-Transport-Security with max-age and includeSubDomains, at which point the browser rewrites http:// to https:// itself before the request leaves the machine. Note the ordering constraint: that header is only honoured when it arrives over a protected connection, so it can never be delivered by the redirect itself.

Real-World Example

A charity publishes an annual report on 99helpers at lowden-trust.99helpers.site and prints the address, without any prefix, on a leaflet. Readers typing it in arrive insecure, are redirected once, and land on the protected page with the padlock intact; the extra hop costs them about 60 milliseconds and nothing else. A hand-built server would have needed a port 80 listener written purely to bounce people away, which is one more thing to misconfigure. Here it is simply how the address behaves.

Common Mistakes

  • Redirecting every insecure request to the home page — a visitor following a deep link to a specific file lands somewhere else entirely and assumes the file is gone
  • Using a 302 because it feels safer — temporary redirects are not cached and pass no consolidation signal, so both addresses stay in the index
  • Setting a long Strict-Transport-Security max-age before the secure site is verified — the browser then refuses the insecure fallback, and you cannot undo it on machines that already saw the header
  • Chaining hops — insecure bare to insecure www to secure www costs two extra round trips that one correctly written rule would have avoided

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →