Every webpage, API call, and file download uses HTTP. Understanding its structure, headers, and the TLS layer that makes it secure lets you debug anything from a broken API to a performance bottleneck.
HTTP Basics#
HTTP is a request-response protocol. A client sends a request; the server replies with a response. Each exchange is independent: HTTP is stateless (the server doesn't remember previous requests by default).
HTTP Methods#
| Method | Semantics | Idempotent | Safe |
|---|---|---|---|
| GET | Retrieve resource | Yes | Yes |
| POST | Create resource / trigger action | No | No |
| PUT | Replace resource entirely | Yes | No |
| PATCH | Partial update | No | No |
| DELETE | Remove resource | Yes | No |
| HEAD | GET but only headers, no body | Yes | Yes |
| OPTIONS | List allowed methods (CORS preflight) | Yes | Yes |
Idempotent = calling it multiple times has the same effect as calling it once.
Safe = doesn't modify server state.
The method word is an instruction about the server's data. Watch one shopper send all five: what each tap does to the shop's records, and why PUT and PATCH are not the same.
Status Codes#
| Range | Meaning | Common codes |
|---|---|---|
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirect | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | Server error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
The first digit says whose move it is. Watch twelve of them happen to one shopper: each code is earned by something she taps, and her screen shows what it means for her.
Important Headers#
Request headers:
Response headers:
Cookies#
Cookies are key-value pairs the server sets on the client (Set-Cookie). The browser sends them back on every subsequent request to the same domain.
| Flag | Meaning |
|---|---|
HttpOnly | JavaScript cannot access this cookie (XSS protection) |
Secure | Only sent over HTTPS |
SameSite=Strict | Not sent with cross-site requests (CSRF protection) |
Max-Age=N | Expires in N seconds |
Authenticating an API#
Because HTTP is stateless, every request has to prove who sent it, and the proof rides in a header: Authorization: Basic …, Authorization: Bearer <token>, an API key header, or a session cookie the browser sends back automatically.
HTTP Versions#
HTTP/1.0#
New TCP connection per request, which is extremely slow for pages with many resources.
HTTP/1.1#
Persistent connections: TCP connection reused for multiple requests. Pipelining: send multiple requests without waiting for responses, but responses must arrive in order (head-of-line blocking).
A new HTTPS connection costs two round trips before the first byte of the page moves: the TCP handshake opens the line, the TLS handshake locks it. Keep that connection open and every later request to the same server skips both, paying only for its own round trip. That is why the second page on a site usually loads faster than the first.
HTTP/2#
- Multiplexing: multiple requests/responses interleaved over one TCP connection, no HTTP-level head-of-line blocking
- Header compression (HPACK): reduces overhead for large/repeated headers
- Server push: server proactively sends resources the client will need
- Binary framing instead of plain text
HTTP/3 (QUIC)#
- Runs over QUIC (UDP-based) instead of TCP
- QUIC bakes TLS 1.3 into the handshake, so 1 round-trip instead of 2
- Per-stream loss recovery: a lost packet in stream A doesn't block stream B
- Built-in connection migration (survive IP address changes, e.g., WiFi → 5G)
HTTPS = HTTP + TLS#
TLS (Transport Layer Security) encrypts the connection. Without it, anyone on the network can read your passwords and data.
What HTTPS does not hide is which site you are on. The site's name goes out in the clear at the start of every connection (the SNI field of the TLS hello), so anyone on the same Wi-Fi can list every site you open. A VPN fixes that by wrapping everything your device sends inside one encrypted tunnel to a VPN server. The Wi-Fi then sees only "talking to a VPN"; the VPN server unwraps each packet and sends it on. The catch: that server now sees every site instead, so you are choosing whom to trust, not removing the need to.
TLS 1.3 Handshake#
Certificate Chain#
The browser verifies each signature up to a trusted root. If any step fails, you see the "Your connection is not secure" warning.
CORS (Cross-Origin Resource Sharing)#
Browsers block JavaScript from making requests to a different origin (protocol + domain + port) than the page. This is the Same-Origin Policy.
CORS lets servers whitelist trusted origins:
Python: Making HTTP Requests#
What to Remember#
- HTTP is stateless and request-response; headers carry metadata about requests and responses
- Methods encode semantics (GET=read, POST=create, PUT=replace, DELETE=remove)
- Status codes: 2xx=success, 3xx=redirect, 4xx=client error, 5xx=server error
- HTTP/2 multiplexes requests; HTTP/3 eliminates TCP head-of-line blocking with QUIC
- HTTPS = HTTP + TLS; the certificate chain proves the server's identity
- Use
HttpOnly + Secure + SameSite=Strictcookies to harden auth sessions