Domains, CDN & Web Delivery

HTTPS

Definition

HTTPS is not a separate protocol so much as an arrangement: the browser opens a TLS connection to the server, checks the certificate it presents, and only then sends the ordinary HTTP request inside it. Requests, responses, headers, cookies and file contents all travel encrypted; the hostname and the rough size and timing of the traffic still leak, but the paths and payloads do not. The default port is 443 rather than 80. The three names people mix up divide neatly: the protocol doing the protecting is TLS, the document proving the hostname is the certificate, and HTTPS is the result you see in the address bar. Browsers stopped rewarding it with a green padlock years ago and now do the reverse — Chrome and Firefox label a plain HTTP page as Not Secure, so the absence is what gets marked.

Why It Matters

A page served without it can be read and altered by anything between the visitor and the server, which in practice has meant injected adverts, rewritten links and swapped downloads. The visible cost is trust: a Not Secure label next to a form asking for an email address stops people filling it in. There are functional consequences too — service workers, the geolocation and camera APIs, push notifications and HTTP/2 all refuse to operate on an unprotected page, so a plain HTTP site quietly loses features rather than warning you. And the transition has an edge case that bites: a page loaded securely that pulls in an image or script over plain HTTP creates mixed content, and the browser either drops the padlock or blocks the resource outright.

How It Works

The browser resolves the hostname, opens TCP port 443 and starts a TLS handshake, sending the hostname in the Server Name Indication field so a server hosting many sites knows which certificate to present. The server returns its certificate chain; the browser validates the signature path to a trusted root, checks the validity dates and confirms the hostname matches. Keys are agreed, and from that point the request line, headers and body are encrypted. A server that also answers on port 80 should not serve content there — it should send an HTTPS redirect with a 301 to the equivalent secure address. Adding a Strict-Transport-Security header then tells the browser to go straight to the protected address for a stated period, typically 31536000 seconds, skipping the insecure hop on later visits.

Real-World Example

A consultant uploads a 3 MB rate card to 99helpers and sends the link, hart-rates.99helpers.site, to a prospective client. The address is protected from the first request, with a certificate issued and renewed by the platform, so the recipient sees no warning and the PDF arrives exactly as published. Had the same file been served from a hand-configured box on port 80, the client's browser would have shown Not Secure beside the address before they had read a word of it.

Common Mistakes

  • Treating it as a padlock icon rather than a property of the connection — the padlock only ever meant the traffic was encrypted, never that the site was trustworthy
  • Serving the same content on both port 80 and port 443 with no redirect — search engines then index two addresses for one page and split the ranking signals between them
  • Hardcoding http:// in image and script tags after a migration — that is precisely what triggers mixed content warnings on an otherwise correct page
  • Enabling Strict-Transport-Security with a long max-age before the secure version is known to work — browsers will honour it and refuse the insecure fallback you were relying on

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 →