HTTP/1.1 — The Foundation

How It Works

HTTP/1.1 is a text-based, stateless, request-response protocol running over TCP. Every interaction follows the same rhythm: the client sends a request, the server processes it, and sends back a response. That simplicity is both its greatest strength and its biggest limitation.

A request consists of three parts: a request line (GET /api/users HTTP/1.1), headers (key-value pairs like Host, Accept, Authorization), and an optional body (for POST/PUT/PATCH). The response mirrors this with a status line (HTTP/1.1 200 OK), headers, and a body.

Methods Matter

The HTTP methods aren't just labels — they carry semantic meaning that caches, proxies, and browsers rely on:

• GET — Safe, idempotent. Cacheable by default. Never use it to modify state.
• POST — Not idempotent. Creates resources. Request bodies expected.
• PUT — Idempotent. Replaces the entire resource at the URI.
• PATCH — Partially updates a resource. Not guaranteed idempotent.
• DELETE — Idempotent. Removes the resource.
• HEAD — Identical to GET but returns only headers. Useful for checking if a resource exists or has changed.
• OPTIONS — Returns allowed methods. CORS preflight requests use this.

# A well-formed HTTP/1.1 request
curl -v -X GET https://api.example.com/users/42 \
  -H "Accept: application/json" \
  -H "Authorization: Bearer eyJhbG..."

Status Codes — The Server's Vocabulary

Status codes are grouped by category, and understanding them saves hours of debugging:

Range	Meaning	Common Codes
1xx	Informational	100 Continue, 101 Switching Protocols
2xx	Success	200 OK, 201 Created, 204 No Content
3xx	Redirection	301 Permanent, 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 Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

The difference between 401 and 403 trips up even experienced engineers. 401 means "the server does not know the client's identity — authenticate first." 403 means "the server knows the client's identity, but access is not permitted."

Caching — The Most Impactful Performance Feature

HTTP caching is the single biggest performance optimization available, and most teams underuse it. The caching system has two complementary mechanisms:

Freshness — How long can a cached response be used without checking the server?

Cache-Control: max-age=3600, public

Validation — Is the cached response still valid?

ETag: "abc123"
If-None-Match: "abc123"   → Server responds 304 if unchanged

The Cache-Control header is the primary mechanism. Key directives:

• max-age=N — Cache for N seconds
• no-cache — Always revalidate (does NOT mean "don't cache")
• no-store — Never cache at all
• public — CDNs and shared caches can store it
• private — Only the browser can cache it

A common mistake: no-cache doesn't prevent caching. It forces revalidation on every use. To prevent caching entirely, use no-store.

Persistent Connections and Pipelining

Before HTTP/1.1, every request required a new TCP connection — a three-way handshake for each image, script, and stylesheet. HTTP/1.1 changed this with persistent connections (keep-alive), allowing multiple requests over one TCP connection.

Pipelining was the next logical step: send multiple requests without waiting for responses. On paper, brilliant. In practice, a disaster. The protocol requires responses to arrive in the same order as requests. If the first response is slow, everything behind it is blocked — head-of-line blocking. Most browsers never enabled pipelining by default, and proxies frequently broke it.

# Without keep-alive (HTTP/1.0 default):
[TCP handshake] → [Request 1] → [Response 1] → [TCP close]
[TCP handshake] → [Request 2] → [Response 2] → [TCP close]

# With keep-alive (HTTP/1.1 default):
[TCP handshake] → [Request 1] → [Response 1] → [Request 2] → [Response 2] → ... → [TCP close]

Browsers worked around pipelining's failure by opening 6 parallel TCP connections per origin. This is the origin of "domain sharding" — serving assets from multiple subdomains to multiply the connection pool. HTTP/2 made this hack obsolete.

Chunked Transfer Encoding

When the server doesn't know the total response size upfront (streaming, server-generated content), it uses chunked transfer encoding:

Transfer-Encoding: chunked

4\r\n
Wiki\r\n
6\r\n
pedia \r\n
0\r\n
\r\n

Each chunk is prefixed with its size in hexadecimal. A zero-length chunk signals the end. This is how servers can start sending data before the full response is generated — critical for time-to-first-byte optimization.

Why HTTP/1.1 Still Matters

It might seem like HTTP/1.1 is obsolete. It's not. Understanding it is essential because:

1. HTTP/2 and HTTP/3 preserve HTTP/1.1 semantics — the methods, headers, and status codes are identical
2. Debugging is easier — it's possible to literally telnet to port 80 and type a request
3. Many internal services still use it — behind a load balancer, the extra complexity of HTTP/2 often isn't worth it
4. Every HTTP library defaults to HTTP/1.1 semantics — even when the transport is HTTP/2

The protocol's simplicity is a feature. When something goes wrong, being able to read the raw bytes in Wireshark or curl -v is invaluable. That's why HTTP/1.1 isn't just history — it's the mental model needed to understand everything that came after it.