HTTP and HTTPS
The protocol behind every web page and API: methods and status codes, safe and idempotent requests, caching headers, how HTTPS keeps traffic private, and what HTTP/2 and HTTP/3 changed.
In a nutshell
- HTTP is request/response: a method and a path go in, a status code, headers and a body come out.
- GET is safe and idempotent, PUT and DELETE are idempotent, POST is neither: this decides what can be retried.
- HTTPS = HTTP inside TLS: encrypted, tamper-proof, and the server proves who it is with a certificate.
- HTTP/2 multiplexes requests over one connection; HTTP/3 runs on QUIC over UDP to avoid TCP head-of-line blocking.
A request and a response
HTTP is a text-based (in HTTP/1.1) conversation: the client sends a request, the server sends a response. Every API call and page load is one of these.
One HTTP exchange
Diagram as text
- Client → Server: GET /api/orders/42 (Accept: application/json)
- Server → Server: look up order 42
- Server → Client: 200 OK (Content-Type: application/json) {…}
Requests have a method (what to do), a path (to what), headers (metadata such as content type, cookies, authentication) and sometimes a body. Responses have a status code, headers and a body.
Methods: safe and idempotent
Two properties of methods matter for system design, because they decide what can be cached and what can be retried after a timeout:
- Safe: does not change anything on the server. Safe requests can be cached and prefetched.
- Idempotent: doing it twice has the same effect as doing it once. Idempotent requests can be retried safely when you are not sure the first one arrived.
| Method | Used to | Safe | Idempotent |
|---|---|---|---|
| GET | Read a resource | Yes | Yes |
| HEAD | Read only the headers | Yes | Yes |
| PUT | Create or replace a resource at a known path | No | Yes |
| DELETE | Remove a resource | No | Yes |
| POST | Create something or trigger an action | No | No |
| PATCH | Partly update a resource | No | Not guaranteed |
Status codes
| Range | Meaning | Ones you will meet |
|---|---|---|
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirect or use the cache | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | The client got something wrong | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests |
| 5xx | The server failed | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
The difference matters for clients: retrying a 4xx usually fails again (fix the request), while a 503 or 504 may succeed later. A 429 means slow down, often with a Retry-After header saying when.
Caching with HTTP headers
HTTP has caching built in. The server tells browsers and CDNs how long a response stays fresh, and how to check whether it changed:
Cache-Control: max-age=31536000, immutablefor files whose name changes when their content does (such asapp.3f9a1c.js): cache for a year.Cache-Control: no-storefor private or always-fresh data.ETagandIf-None-Match: the client asks "has it changed since this version?" and gets a tiny 304 Not Modified if not.
HTTPS: HTTP over TLS
Plain HTTP travels as readable text: anyone on the network path (public Wi-Fi, an ISP) can read or change it. HTTPS wraps HTTP in TLS, which gives three guarantees: encryption (nobody can read it), integrity (nobody can change it unnoticed) and authentication (the server proves its identity with a certificate signed by a trusted certificate authority).
TLS 1.3 handshake (simplified)
All steps One round trip after the TCP connection: agree keys, check the certificate, then send encrypted HTTP.
- The browser says hello, lists the ciphers it supports and sends its half of a key exchange.
- The server replies with its half, its certificate and proof it holds the certificate's private key.
- The browser checks the certificate chain and the hostname, and both sides derive the same session keys.
- The browser finishes the handshake and can send its first encrypted request straight away.
- Everything from now on is encrypted with the session keys.
Diagram as text
- The browser says hello, lists the ciphers it supports and sends its half of a key exchange.
- The server replies with its half, its certificate and proof it holds the certificate's private key.
- The browser checks the certificate chain and the hostname, and both sides derive the same session keys.
- The browser finishes the handshake and can send its first encrypted request straight away.
- Everything from now on is encrypted with the session keys.
HTTPS is the default now: browsers mark plain HTTP pages as "Not secure", and free certificates (for example from Let's Encrypt) removed the cost. Load balancers and CDNs usually terminate TLS: they decrypt at the edge and talk to app servers over a private network (or re-encrypt for end-to-end security).
HTTP/1.1, HTTP/2 and HTTP/3
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| Runs over | TCP | TCP | QUIC over UDP |
| Requests per connection | One at a time; browsers open several connections per host | Many at once (multiplexed streams) | Many at once, with independent streams |
| Headers | Plain text, repeated on every request | Compressed (HPACK) | Compressed (QPACK) |
| Head-of-line blocking | Per connection | Gone at the HTTP level, but one lost TCP packet stalls all streams | Gone: a lost packet only stalls its own stream |
| Connection set-up | TCP + TLS | TCP + TLS | Combined: as little as one round trip, zero on resumption |
HTTP/3 also survives network changes better: a phone switching from Wi-Fi to mobile data can keep the same QUIC connection, because QUIC identifies connections by an ID rather than by IP address and port.
Common mistakes
- Using GET for actions that change data. Crawlers, prefetchers and caches will happily trigger them.
- Retrying POST requests automatically without idempotency keys.
- Returning 200 with an error message in the body: clients, caches and monitoring all rely on status codes.
- Caching personalised responses at a CDN because
Cache-Controlwas left to defaults.
Interview questions
Try answering out loud before you open each one.
What is the difference between PUT and POST?
PUT creates or replaces the resource at a URL the client specifies, and is idempotent: sending it twice leaves the same state. POST asks the server to create something or perform an action, usually at a URL the server chooses; sending it twice may create two resources, so it is not idempotent.
Why is HTTP/2 faster than HTTP/1.1 for a page with many assets?
HTTP/1.1 handles one request at a time per connection, so browsers open several connections and assets queue behind each other. HTTP/2 multiplexes many requests over one connection with compressed headers, removing that queueing and the cost of extra connections.
What does HTTPS protect against, and what not?
It prevents eavesdropping and tampering between the client and the server that terminates TLS, and proves the server's identity. It does not protect against a compromised server, bugs in your app, or a user who ignores certificate warnings, and the destination hostname is still visible to the network in most cases.
Check yourself
Related topics
Further reading
- An overview of HTTP MDN Web Docs
- RFC 9110: HTTP Semantics IETF, 2022
- RFC 9114: HTTP/3 IETF, 2022
Your notes
Saved in this browser as you type.
Finished this topic?
Mark it read to track your progress, then carry on with the next one.