HTTP, HTTPS & The Web Stack

The Web runs on HTTP (HyperText Transfer Protocol), a beautifully simple request/response conversation. Your browser (the client) sends a request; a server sends back a response. HTTP is stateless — each request stands alone, and the server remembers nothing between them unless you add state deliberately (see cookies).

A request has a method (the verb), a path, headers, and sometimes a body. The methods carry meaning:

• GET — retrieve a resource; should have no side effects (safe).
• POST — submit data / create something.
• PUT — replace a resource; PATCH — partially update it.
• DELETE — remove a resource.
• HEAD — like GET but headers only; OPTIONS — ask what's allowed.

GET and HEAD are safe (read-only); GET, PUT, and DELETE are idempotent (repeating them has the same effect as doing them once). These properties are the backbone of REST API design.

Every response starts with a three-digit status code whose first digit tells you the family:

Two frequently confused ones: 401 Unauthorized actually means "unauthenticated — I don't know who you are," while 403 Forbidden means "I know who you are and you still can't."

Headers are key-value metadata on both requests and responses: Content-Type, User-Agent, Authorization, Cache-Control, and many more. They control caching, content negotiation, authentication, and — crucially — security policy.

Since HTTP forgets everything between requests, how does a site keep you logged in? Cookies. On login, the server sends a Set-Cookie header containing a session identifier; your browser stores it and attaches it to every subsequent request to that site. The server looks up the identifier in its session store and recognizes you.

That session cookie is, functionally, your temporary password. If an attacker steals it, they are you — no password needed. This is session hijacking, and it's why cookie flags matter enormously:

• Secure — the cookie is only sent over HTTPS, never plaintext HTTP.
• HttpOnly — JavaScript cannot read the cookie, blunting theft via cross-site scripting (XSS).
• SameSite — restricts whether the cookie is sent on cross-site requests, defending against cross-site request forgery (CSRF).

Modern apps increasingly use tokens (like JWTs) instead of server-side sessions, but the core risk is identical: whoever holds the credential holds the identity.

HTTPS is just HTTP running inside TLS (Transport Layer Security, the successor to SSL). TLS provides three things at once: confidentiality (eavesdroppers see only ciphertext), integrity (tampering is detected), and authentication (you're really talking to the site named on the certificate, vouched for by a Certificate Authority).

At a high level, a TLS handshake does this:

1. ClientHello: the browser offers its supported TLS versions and cipher suites, plus a random value.
2. ServerHello + Certificate: the server picks a cipher, sends its certificate (containing its public key, signed by a CA), and its own random value.
3. Key exchange: using something like ECDHE (elliptic-curve Diffie–Hellman), both sides derive the same shared symmetric session key without ever sending it across the wire.
4. Finished: both switch to fast symmetric encryption for the actual data.

Modern TLS 1.3 streamlined this to a single round trip (and 0-RTT for resumption) and removed a pile of old, weak options. The Diffie–Hellman step provides forward secrecy: even if the server's long-term key is later stolen, past sessions stay unreadable.

The original HTTP/1.1 opened separate TCP connections and largely handled one request at a time per connection, causing head-of-line blocking: one slow response stalled everything behind it.

HTTP/2 (2015) fixed the application layer with multiplexing — many concurrent streams over a single connection — plus a compact binary framing format and header compression (HPACK). But it still ran on TCP, so a single lost packet could stall all streams at the transport layer. The blocking moved down a floor.

HTTP/3 solves that by abandoning TCP entirely and running over QUIC, a new transport built on UDP. QUIC implements its own streams, loss recovery, and — notably — has TLS 1.3 baked in, so the transport and crypto handshakes happen together. Because each QUIC stream is independent, one lost packet only stalls its own stream, not the others.

A handful of response headers harden a site against whole classes of attack — and their absence is a common audit finding:

• HSTS (Strict-Transport-Security): tells browsers to only ever use HTTPS for this domain, defeating downgrade and SSL-stripping attacks. Sites can even be pre-loaded into browsers so the very first visit is protected.
• CSP (Content-Security-Policy): a whitelist of where scripts, styles, and other resources may load from. A well-tuned CSP is one of the strongest defenses against cross-site scripting, since injected inline scripts simply won't execute.
• X-Content-Type-Options: nosniff: stops the browser from second-guessing declared content types (MIME sniffing), which attackers abuse to make a file execute as script.
• X-Frame-Options / CSP frame-ancestors: prevents your page from being embedded in a hostile iframe (clickjacking).
• Referrer-Policy: controls how much URL information leaks to other sites.