HTTP & HTTPS

HTTP (HyperText Transfer Protocol) is the language a browser and a web server use to ask for and deliver pages, images, JSON and files. Every web API you call from an app speaks it too. HTTPS is the same protocol wrapped in an encrypted tunnel called TLS. This lesson shows what an HTTP message looks like on the wire, what the codes and headers mean, and what actually happens when you see the padlock.

What Is HTTP?

HTTP is a request and response protocol. The client (a browser, a mobile app, or a command-line tool such as curl) opens a connection, sends one request, and the server sends back one response. Three ideas are worth remembering:

• The client always speaks first. A server cannot push a message to a plain HTTP client that did not ask (that is the gap WebSocket fills).
• It is stateless. Each request stands alone. The server does not remember you between requests unless you send something that identifies you, such as a cookie or a token.
• It rides on TCP. HTTP relies on TCP to deliver the bytes reliably and in order. Plain HTTP uses port 80, HTTPS uses port 443.

Anatomy of a Request and a Response

In HTTP/1.1 both messages are plain text: a first line, some headers, an empty line, and an optional body.

The Common Methods

The method says what you want to do with the resource. Two properties matter to API designers: a method is safe if it only reads and changes nothing on the server, and idempotent if sending it ten times has the same effect as sending it once.

Status Codes

The first digit tells you the family; the rest tells you the detail.

Headers You Will See Everywhere

Why Plain HTTP Is Not Safe

With plain HTTP the text of the request and the response travels exactly as shown above. Everyone on the path between you and the server can read it: other people on the same café Wi-Fi, a router, your internet provider. They can also change it on the way. Passwords, session cookies and form data would be visible, and a page could be altered before it reaches you. That is the problem HTTPS solves.

HTTPS = HTTP + TLS

HTTPS does not change HTTP at all. The same requests and responses are simply sent inside a TLS (Transport Layer Security) session, which sits between HTTP and TCP.

TLS makes three promises:

• Privacy: the traffic is encrypted, so an eavesdropper only sees scrambled bytes.
• Integrity: any change to the data on the way is detected.
• Identity: a certificate proves you are talking to the real owner of the domain, not an impostor.

The TLS Handshake

Before any HTTP is sent, the two sides agree on the settings and on a secret key. With TLS 1.3, the version used by most sites today, this takes one round trip after the TCP connection is open.

1. ClientHello. The browser lists the TLS versions and cipher suites it supports and sends its half of a key exchange. It also names the website it wants (the "server name").
2. ServerHello. The server picks a cipher suite and sends its half of the key exchange. From this point both sides can compute the same secret key, and everything that follows is encrypted.
3. Certificate and proof. The server sends its certificate and a signature that proves it holds the matching private key, then a Finished message that covers the whole conversation so far.
4. Finished. The browser verifies the certificate and the Finished message, and sends its own. Now the first HTTP request can go out, encrypted.

A detail that surprises many people: slow public-key maths is used only to agree on a shared secret. The actual page data is then encrypted with a fast symmetric cipher such as AES-GCM or ChaCha20-Poly1305. The key exchange is also done with fresh temporary keys each time, so recording today's traffic and stealing the server's key next year does not let anyone decrypt it (this is called forward secrecy).

Certificates and Who to Trust

Encryption alone is not enough: you could be encrypting a conversation with an attacker. A certificate says "this public key belongs to example.com", and it is signed by a certificate authority (CA). Your browser and operating system ship with a list of root CAs they trust. A website usually sends its own certificate plus an intermediate one, and the browser follows the signatures up to a root it already knows.

Certificates are valid for a limited time (months, not years) and must be renewed. Free certificate authorities such as Let's Encrypt made HTTPS the default for almost every site.

What HTTPS Does Not Hide

• Which site you visit. The domain name is usually visible through the DNS lookup and the server name in the ClientHello. The page you opened and the data you sent are hidden; the fact that you contacted example.com is not.
• The IP address and the amount and timing of traffic. An observer can still see roughly how much you sent and when.
• Whether the website itself is honest. A phishing site can have a perfectly valid HTTPS certificate for its own domain. The padlock means "private connection to this domain", not "this domain is trustworthy".

HTTP Versions at a Glance

The meaning of methods, status codes and headers is the same in all three versions. Only the way the messages are packed for the network changes.

Try It Yourself

The curl tool can show you a whole HTTPS exchange. The -v flag prints the handshake and both messages:

curl -v https://example.com

The output differs between curl versions and operating systems, but you will see lines starting with * (connection and TLS details), > (the request curl sent) and < (the response it received), similar to:

* Connected to example.com port 443
* TLSv1.3 (OUT), TLS handshake, Client hello
* TLSv1.3 (IN), TLS handshake, Server hello
> GET / HTTP/2
> Host: example.com
< HTTP/2 200
< content-type: text/html

To see only the response headers, use curl -I https://example.com. In JavaScript the same request looks like this:

fetch('https://api.example.com/items/1')
  .then(function (response) {
    console.log(response.status);        // 200
    return response.json();
  })
  .then(function (item) {
    console.log(item);
  });

Common Mistakes

• Mixed content. Loading a script or image over http:// from an HTTPS page. Browsers block or warn about it.
• An expired or mismatched certificate. The browser shows a full-page warning. Renew on time and make sure the certificate covers the exact domain name you use.
• Leaving plain HTTP reachable. Redirect http:// to https://, and consider the Strict-Transport-Security header so browsers go straight to HTTPS next time.
• Secrets in the URL. Query strings end up in logs, history and referrer headers, even over HTTPS. Send tokens in a header and sensitive data in the body.
• Using GET to change data. Crawlers, prefetchers and caches assume GET is safe. Use POST, PUT or DELETE for changes.