Stage 3 · Build
HTTP, HTTP/2 & gRPC
HTTP/1.1 Fundamentals
Methods, status codes, headers, caching, Keep-Alive, and chunked encoding.
The Request-Response Model
HTTP is a stateless, text-based (HTTP/1.0) or binary (HTTP/2+) protocol built on a request-response model. The client sends a request, the server sends a response. Each request and response consists of a start line, headers, an empty line, and an optional body.
Request:
GET /api/users?page=1 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>
Response:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234
{"users": [...]}The start line of a request contains the method, path, and HTTP version. The start line of a response contains the status code and reason phrase. Headers provide metadata about the request or response.
HTTP Methods
| Method | Idempotent | Safe | Purpose |
|---|---|---|---|
| GET | Yes | Yes | Retrieve a resource |
| POST | No | No | Create a resource or trigger processing |
| PUT | Yes | No | Replace a resource entirely |
| PATCH | No | No | Partially modify a resource |
| DELETE | Yes | No | Remove a resource |
| HEAD | Yes | Yes | Same as GET but no body |
| OPTIONS | Yes | Yes | Describe allowed methods |
Idempotent methods (GET, PUT, DELETE) produce the same result whether called once or ten times. This is critical for retries — if a PUT request times out, you can safely retry because the result is the same. POST is not idempotent, so retrying a POST may create duplicate resources.
Status Codes
| Code | Category | Common Examples |
|---|---|---|
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirection | 301 Moved, 304 Not Modified, 307 Temporary |
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 404 Not Found |
| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
200 OK - Successful request, body contains result
201 Created - Resource created, Location header has URL
204 No Content - Success but no body (DELETE response)
301 Moved Permanently - Client should use new URL forever
302 Found - Temporary redirect, repeat with original method
304 Not Modified - Use cached version (conditional GET)
400 Bad Request - Malformed syntax or invalid data
401 Unauthorized - Authentication required
403 Forbidden - Authenticated but not authorized
404 Not Found - Resource does not exist
429 Too Many Requests - Rate limited, Retry-After header
500 Internal Server Error - Unhandled exception
502 Bad Gateway - Upstream server returned invalid response
503 Service Unavailable - Server overloaded or down for maintenance
504 Gateway Timeout - Upstream server too slowThe status code category (first digit) tells you the general outcome. Always return the correct status code — 200 with an error message in the body confuses clients and monitoring tools.
Essential Headers
# Request headers
Host: example.com # Required in HTTP/1.1
Authorization: Bearer <token> # Authentication
Content-Type: application/json # Body format
Accept: application/json # Desired response format
User-Agent: my-app/1.0 # Client identification
If-None-Match: "etag123" # Conditional request
If-Modified-Since: Sat, ... # Conditional request
# Response headers
Content-Type: application/json
Content-Length: 1234
Cache-Control: max-age=3600 # Caching rules
ETag: "etag123" # Response fingerprint
Location: /new-url # Redirect target
X-Request-Id: abc123 # Distributed tracingHeaders are how HTTP communicates metadata. Content-Type tells the client how to parse the body. Cache-Control tells proxies how to cache. Authorization tells the server who is asking.
Keep-Alive and Chunked Encoding
HTTP/1.1 defaults to persistent connections (Keep-Alive). Without it, every request opens a new TCP connection — expensive due to the three-way handshake. Keep-Alive reuses the same TCP connection for multiple requests.
# Keep-Alive header controls connection reuse
Connection: keep-alive
Keep-Alive: timeout=5, max=100
# Chunked Transfer Encoding (unknown content length)
HTTP/1.1 200 OK
Transfer-Encoding: chunked
1a
First chunk of data...
1b
Second chunk of data...
0
Chunked encoding lets the server start sending data before knowing the total size. Each chunk is prefixed with its length in hex. A zero-length chunk signals the end. This is common in streaming responses.
HTTP/1.1 Keep-Alive is limited by head-of-line blocking — only one request can use the connection at a time. HTTP/2 fixes this with multiplexing. For HTTP/1.1, connection pools in your HTTP client are essential for performance.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.